UniverseUniversity


Home Projects Jobs Clientele Contact

uu


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

Re:



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
total-knowledge.com
culturedialogue.org




--
Alexey Parshin,
http://www.sptk.net

Authoright © Total Knowledge: 2001-2008