Member Pages .... Re: [thesite] user selecteble stylesheets..
rudy
r937 at interlog.com
Tue Oct 16 22:36:38 CDT 2001
> then, you got some 'splainin to do...
>
> i was trying to guess a reason for the PRIV field
> in the MEMBER table
ah, sorry ricky, like i said, i jumped into this thread near the end
yes, you're right, of course
except that a consistent implementation would require that the member table
priv overrides all member attributes, not just skills -- but i assume you
were using skills only as as example
rudy
"nap time is any time"
p.s. to michele
> http://members.evolt.org/rudy/evolta.gif
>
> Looks like to me the MemberId will be stored in the User table.
yup
> So each user will only have one MemberId.
exactly!!! however, don't assume that this means only one user per
member!!!
the "child" table (which is on the "many" side of a one-to-many
relationship) always carries the foreign key or pointer to the "parent"
table (which is on the "one" side of a one-to-many relationship)
in the diagram, the "many" side of the relationship has the solid dot on
the end of the line
i can't figure out how to get ERwin not to put that stupid lozenge/diamond
on the other side, because it's not consistent how it does it
anyhow...
the trick to remembering which side of the one-to-many relationship is the
child and which is the parent, is to see which one carries the foreign key
the FK is *always* in the child
if it were in the parent, then there'd have to be an array of them, one
per child -- in other words, a repeating group, the biggest no-no in
normalizing a database design
i guess this isn't the right time to mention that in sql-3 (the next sql
standard), arrays are supported...
More information about the thesite
mailing list