Re: UU database: problem tables

["Alexey Parshin" <alexeyp@gmail.com>]

2006/9/26, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:

Alexey Parshin wrote:
>
>     Alexey Parshin wrote:
>     > Actually,
>     > I expected that single problem may be  offered to many students,
>     and
>     > every student may have personal solution with personal access and
>     > personal status.
>     That is correct. However, status is not part of ACL entry. That is why
>     they have to be separate
>     tables. Basically status may stay ( i.e. for scoring purposes)
>     even after
>     student loses any access
>     to the problem.
>
> Interesting. In this case,
> 1) The present structure, one problem -> many solutions(one per person
> or even many per person) is correct, isn't it? Please, confirm.
I actually didn't think about more then one solutions
per-person+problem, but I guess it is actually possible.
At least I don't see any good reason to limit database from allowing it.
> 2) Status isn't a part of the access and  may stay even after a person
> lost the access to the object. It may be: not started, working on,
> completed, failed.. Status may be a part of ACL only because it's
> convenient - we don't have to create a separate set of status tables
> for topic, problem, course etc..
Except status _is_ different, and may stay after access is revoked. So
it has to be in different tables.

Actually, revoking access completely is probably a rare case. We may want to revoke a modify access - after the object is completed by person. 
We may even revoke access by indicating "no access" in ACL record, and still have status. If this happens rare - we can save space and gain performance.

If you still don't like it - then I'd create a set of status tables.

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