[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: UU database: problem tables
Alexey Parshin wrote:
> 2006/9/26, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com
> <mailto: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.
Depending on how we do it, I think it may actually be frequent thing to
happen, especially on "proprietary"
server, where people don't have "view" access by default. Or if we
decide that "no access record has access XYZ", which
is more flexible. In this case ACL tables will be more or less
manageable in size.
> 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.
Well, again, if we make deleting access record completely a rare event,
then it makes sense.
I don't know - maybe you are right, and we should keep "status" and ACL
info together. But in this case
we need to change naming. Also, take into consideration, that, for
example, for problem, "status" is a fairly
complex thing - and further, it is _different_ for different access levels.
For student it's solution he supplied, time it took him to solve the
problem, score he got, etc.
For someone with edit access, status will include things like where/what
he is editing, etc.
> If you still don't like it - then I'd create a set of status tables.
>
> --
> Alexey Parshin,
> http://www.sptk.net
--
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com