Home Projects Jobs Clientele Contact


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Well, in this case it's pretty simple. Every completed test gets a vote, and we can always find all the tests within the topic or with the course (TLT) - for all the tree of topics.

I'm starting to suspect, that we need an acceleration field top_level_topic in every topic.. A slight de-normalization..

2006/12/18, Anatoly Volynets <av@total-knowledge.com>:
Sounds reasonable.

Ilya A. Volynets-Evenbakh wrote:
> We could limit voting to only those who tried to pass an object. I don't
> know if its a good idea, but if we do this, there will be no need for
> separate
> voting tables.
> Alexey Parshin wrote:
>> A question, before I start implementing this structure. We agreed that
>> difficulty level doesn't affect access to UMO. So, from any
>> standpoint, it is just a number on the screen. Implementing this
>> number, however, requires the vote counter and average vote. This, in
>> turn, requires a table per UMO type. Now, the question:
>> Does implementing a community difficulty level worth implementing 5..7
>> tables plus corresponding stored procs?
>> I can, of course, make an economy class implementation - all UMO'
>> votes in the single table (victimize the data integrity).. But still?
>> I'm starting after your command.
>> 2006/12/16, Anatoly Volynets < av@total-knowledge.com
>> <mailto:av@total-knowledge.com>>:
>>     I don't remember that agreement, but I need two part difficulty level
>>     (one part set for Repository by community, another  set within the
>>     course or between courses of this author by this author) as I
>>     described it.


Anatoly Volynets, Co-Founder

Alexey Parshin,

Authoright © Total Knowledge: 2001-2008