On 13/7/2010 4:54 AM, Carsten Klein wrote:
However, a User may also have Preferences, Session information, and
probably many other kinds of data attached to them which is not a
Permission, which a group may not (does not?) have.
One could suggest that a group might provide default settings for a user.
One could suggest that. Assuming you continue the trend of not
distinguishing between User and Groups, however, such a suggestion would
still be more easily facilitated - if not downright require -
Users/Groups to be moved to their own table.
From a purely normalisation basis, I need only point to the diagram on
http://trac.edgewall.org/wiki/TracDev/DatabaseSchema, and the
/ridiculous/ number of tables that have some sort of User field of type
'text'. In terms of scalability, creating a User table and having other
tables reference an integer ID in it could /significantly/ improve
performance and use of space on large-scale installations.
Hm, I do not think so. Yes, the redundant book keeping of the username can
be a problem with backends that do not optimize on string storage. But
since the username is a unique id, I think that it is correct in using it
this way. Btw. what if a user deletes his or her account? As of now, the
username will still be available, and no personal data whatsoever must be
retained.
Unless you're very, /very/ careful about how you store it, then the DB
isn't going to know to/know how to optimise Joins involving that data.
It might optimise storage if you're lucky, but I wouldn't bet on it.
Regardless of whether it optimises the joins properly, it's /still/
quicker to do joins on Integers than Strings; having the lookup ID in
one table, as opposed to distributed across every table that uses a
username allows the DB to optimse queries involving users more
efficiently (see the post about Wizards on Crack); and ripping at
minimum the Username out to its own table with an integer ID would mean
you have /definitely/ optimised the storage of those strings.
As a rule, DBs are very good at what they do so long as you design them
to allow them to do their job properly. If you don't, then its mostly
pot-luck as to whether your queries run well, and your data is stored
efficiently.
- Josh
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
