[dev] Some input on groups

[Jason M. Felice]

I haven't seen anything on the user/group stuff (I do selectively read the
lists tho, sorry), but I've implemented a pretty large system and learned
from a few mistakes.  So FYI, this is my experience:

1) Don't make fields which can contain a user or a group.  This makes life
   much more difficult: you can't use foreign key constraints, queries get
   much more complicated and require unions.  Data normalization is shot.
   Performance is shot.
2) Instead, make all of these fields group references.  They can be groups
   with only one user.
3) This means you will need `unnamed' groups.  These are groups with a NULL
   name (although they still need a key).
4) Groups have reference counts so you know when you can clean them out.
   (You only need to clean out unnamed groups.)
5) A `group edit' field will, if the group is unnamed, read in the top-level
   list of members and let you edit a comma-separated list.  If the group
   is named, you just edit that.
6) If groups can have subgroups (like our system does), keep separate
   group_user and group_group tables (same reason as #1).

I can't justify this for work, but I've thought about it and I'm willing to
spend some personal time on it (if everyone agrees on it, of course).

Thoughts?

-- 
 Jason M. Felice
 Cronosys, LLC <http://www.cronosys.com/>
 216.221.4600 x302