Re: baseball league db design
Date: Sun, 25 Jan 2004 10:28:06 -0500
Message-ID: <NNGdnYwzX_c2fY7dRVn-hg_at_golden.net>
"John O'Conner" <jsoconner_at_earthlink.nospam.net> wrote in message
news:1sLQb.26779$zj7.6117_at_newsread1.news.pas.earthlink.net...
> Karel Miklav wrote:
> > John O'Conner wrote:
> >
> >> One other thing...many of the participants share the same address. For
> >> example, parents, siblings in the same league, etc. Does it seem
> >> reasonable to store addresses separately in an Address table? Then
> >> each participant would have a foreign key to an Address.
> >
> >
> > It seems like the only right way from the point of DB design, but there
> > is a slight problem with input; some people will enter street name as
> > '4th of July', some 'Fourth of July Street'. If you're prepared to
> > handle this...
>
> ???. I don't understand your comment. '4th of July Street'? I'm sure you
> are making a good point, but since I really don't have much db
> experience, I'm not understanding. Why would creating a separate Address
> table encourage users to write a date into the address?
He chose a poor name. Get rid of "of July", and I think it becomes clearer. He is making the point that two users will enter the same address differently. One will use a numeral and one will spell the number with letters.
It can actually be worse than that. If you are at all familiar with Manhattan, consider what happens when one user enters "6th Avenue" and another enters "Avenue of the Americas".
Separating the addresses into a different table runs the risk that the user will overtype the address information when one person moves automatically moving everyone at the same address.
No right answer exists for all databases. Whether an address is a full-blown entity or only descriptive text will depend on the business rules. Received on Sun Jan 25 2004 - 16:28:06 CET