|
|
Posted by David Cressey on 08/15/07 15:29
"Captain Paralytic" <paul_lautman@yahoo.com> wrote in message
news:1187191510.809376.63070@b79g2000hse.googlegroups.com...
> On 15 Aug, 16:12, Doug_McMa...@yahoo.com wrote:
> > On Aug 15, 4:08 am, Summercooln...@gmail.com wrote:
> >
> > > I wonder instead of just brainstorming, there probably is
> > > a very standard and a simple way to do database schema design.
> >
> > > let's say we are doing a website. the user can go over
> > > and type in the movie name and zipcode, and the website
> > > will return all the theaters showing that movie and at what
> > > time, for theaters in THAT zipcode only (for simplicity).
> >
> > > so how do we just start and use a standard method that
> > > can be simple and very accurate to ensure good tables design?
> >
> > 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.
>
> Wouldn't it be one-to-many between ZipCodes and Theatres or do you
> really have theatres that big?
>
I know of a theater in northern Vermont/southern Quebec that straddles the
international border.
An unusual case, though. Not worth altering the model.
Navigation:
[Reply to this message]
|