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?

On Aug 15, 1:08 pm, 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?

The standard method is to make a functional design based upon the end-
users information needs.
The determine your entities and the relations between entities, then
you convert your entities to tables, and your functions to screens.
This is basically what products like Designer and JDeveloper do.
Entity Relationship Modeling is a department of Information Science.
What you describe is taking a pencil, sticking your thumb in the air,
and starting 'somewhere'. This is called Woodshed Modeling.
Regrettably this is how most applications are build nowadays. This
won't work, ever.

--
Sybrand Bakker
Senior Oracle DBA

On Aug 15, 1:30 pm, sybrandb <sybra...@gmail.com> wrote:
> On Aug 15, 1:08 pm, 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.

Yes, the way is indeed simple. First, read books like "Handbook of
Relational Database Design"

http://www.amazon.com/Handbook-Relat...7036320&sr=1-1

After that, you need a few month of making mistakes. After that,
things become very standard and simple - just as with writing software
in general >-

<Summercoolness@gmail.com> wrote in message
news:1187176120.886269.130090@z24g2000prh.googlegr oups.com...
> 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?
>

If you want to get an overview of what data modeling and table design are
all about, take a look at the outline in this website:

http://www.utexas.edu/its/windows/da.../overview.html

These techniques are overkill for the problem you outlined. But if the
information needs grow, as they always do, you will soon be in the
territory where you need these techniques or something like them.

On Aug 15, 5:21 am, "David Cressey" <cresse...@verizon.net> wrote:
> <Summercooln...@gmail.com> wrote in message
>
> news:1187176120.886269.130090@z24g2000prh.googlegr oups.com...
>
> > 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).

Nowadays when I go for interviews, many interviewers hope that
I can produce a schema in just 2, 3 minutes...

So I wonder for the example above, is there a 2 minute way of thinking
to produce the solution?

Summercoolness@gmail.com wrote:

> On Aug 15, 5:21 am, "David Cressey" <cresse...@verizon.net> wrote:
>
>><Summercooln...@gmail.com> wrote in message
>>
>>news:1187176120.886269.130090@z24g2000prh.google groups.com...
>>
>>>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).
>
> Nowadays when I go for interviews, many interviewers hope that
> I can produce a schema in just 2, 3 minutes...
>
> So I wonder for the example above, is there a 2 minute way of thinking
> to produce the solution?

I suggest you stop interviewing for idiots. They won't advance your
career any.

On Aug 15, 7:57 am, Summercooln...@gmail.com wrote:
> On Aug 15, 5:21 am, "David Cressey" <cresse...@verizon.net> wrote:
>
> > <Summercooln...@gmail.com> wrote in message
>
> >news:1187176120.886269.130090@z24g2000prh.googleg roups.com...
>
> > > 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).
>
> Nowadays when I go for interviews, many interviewers hope that
> I can produce a schema in just 2, 3 minutes...
>
> So I wonder for the example above, is there a 2 minute way of thinking
> to produce the solution?

The less time you spend in design the more time you'll spend later in
development costs as your 'model' will show its weaknesses (such as
being totally unscalable) and require MORE work than it would have
taken to build the application properly.

I suggest you stop being lazy and start being smart.


David Fitzjarrell

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.

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?

"Captain Paralytic" <paul_lautman@yahoo.com> wrote in message
news:1187191510.809376.63070@b79g2000hse.googlegro ups.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.