|
|
Posted by William Robertson on 08/15/07 16:02
On Aug 15, 4:39 pm, 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?
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).
Navigation:
[Reply to this message]
|