|
|
Posted by Doug_McMahon on 08/15/07 16:02
On Aug 15, 8:25 am, Captain Paralytic <paul_laut...@yahoo.com> wrote:
> 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?
You're right, I said that backward, sorry, though the fkey would still
be from Theater to ZipCode as stated.
Navigation:
[Reply to this message]
|