> can someone explain exactly what the intended use of
> Attributes was? is it member attributes, general attributes,
> or what?
would you like the quickee explanation or the detailed article i've been
promising for a year or so to write?
attribute ---- 1-m ---- membattr ---- m-1 ---- member
sample attributes: url, phone, icq#, photo
membattr was originally shown in early data model diagrams as having a pk
consisting of the concatenated fk's to member and attribute -- that's
wrong, as we do want multiple occurrences of the same concatenated fk's (a
member can list more than one url, for example), so membattr has its own
sequence-generated pk
helps?
Q: how do we deal with attributes that people want to enter that are not
"predefined" in the attributes table?
A: with any number of inventive solutions -- i'm leaning towards "parent
cascade" (insertion of a child record for a parent that does not exist
automatically creates the parent)
why not just do away with the attributes table, and toss the name of the
attribute into the membattr table? this avoids the predefined problem, but
it tends to bloat the database
besides, there are so many common attributes that people will want to
specify that it makes sense to offer the common ones on a number of
pulldowns or text input fields (please ask me to elaborate if i haven't
explained this advantage well enough)
rude the sql dude
(playing around with taglines; this was one of the early rejections)