Re: standard and easy way to do schema design

On Aug 15, 8:40 am, 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?

Something to ask your interviewer. As you discover relationships you need to make that decision. The ZipCode is a domain. Since there's a limited number of them, you may want a table of them just to capture the domain, support a poplist on the website, capture other properties of the ZipCode like an approximate name for the location, etc. Received on Wed Aug 15 2007 - 18:05:34 CEST