Member Pages .... Re: [thesite] user selecteble stylesheets..

[rudy]

> 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...