Re: standard and easy way to do schema design

On Aug 15, 4:39 pm, Summercooln..._at_gmail.com wrote:
> > You could start with atomic pieces of information and then look for
> > relationships between them. For example, list Movies, Theaters, and
> > ZipCodes on the board. Then it should be clear that there is a many-
> > to-many relationship between Movies and Theaters, so you can add a
> > relation for that. Then it should also be clear that there is a many-
> > to-one relationship between ZipCodes and Theaters, so you can create a
> > foreign key from Theaters to ZipCodes. It's not a substitute for real
> > design work, but it might be enough for the 2-minute interview quiz.
>
> will zipcode be just a property (a field) inside the theater table,
> or will zipcode need to be a table itself?

That is a design question. It depends whether you want to maintain a set of unique zipcodes to validate against ond choose from, whether there is more information you can store against each zipcode (city? state?), and so on.

btw just to nitpick, it could be an attribute of an entity (if we are talking about a logical model) or a column of a table (if we are talking about a physical model), but not a "field". Fields belong in files (or else they are green things with cows in them). Received on Wed Aug 15 2007 - 18:02:44 CEST