[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Database schema [was: UU tools]
Alexey Parshin wrote:
> It's a C++ approach, with no database support for integrity :(
> Object id can be anything, and database can't prevent using course id
> for say, topic id. Foreign keys to the actual tables wouldn'd work in
> such situation. :(
Yes, I realize that. And I'm not happy about that.
>
> The alternative approach is to have separate tables for different
> relations, like course_acl, topic_acl, etc.. It makes us to have
> multiple tables, but then we have foreign keys.
> In order to satisfy fluffy C++ programmers, however, we may also have
> a view - a union of all the acl chunks looking as you defined..
Well, if we follow your idea, and all of this data access id done
through stored procedures, I really don't need to know if you have
single ACL table, multiple ACL tables, view that joins them or anything
else ;-)
To be honest, I don't remember what prompted me to think about having
global ACL table. I don't think it is more efficient in
any way.
Ooh.. Yeah - if we want to go in other direction: show me all objects
for which given user is author. OTOH, we'd still have
to search all actual object tables. This is where LDAP queries win over
SQL queries ;-)
Anyways, I'm definitely not married to the idea of having single ACL table.
The important part is for each access action to be separate. i.e. modify
doesn't imply study (write doesn't mean read ;-),
etc. Then we can have set of roles which are just groupings of permissions.
--
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com