|
|
Posted by Doug_McMahon on 08/15/07 16:05
On Aug 15, 8:40 am, Summercooln...@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.
Navigation:
[Reply to this message]
|