I've recently had my work reviewed by somebody who made the assertion that
my database was never going to work with so few tables. I only got this
news second hand though, I haven't talked to the person himself yet.

What I understand he said is that for the type of system I'm creating I'd
need many, many more tables, He made reference saying that eBay has
hundreds to thousands of tables managing all their data. I find it hard to
believe that so many tables would be necessary.

I passed all my classes on database management in college, I don't remember
anybody ever telling us that we'd need to create databases with so many
tables. In fact, the impression that I'm left with is that we should do our
best to make our database design as lean, mean, and easy to understand as
possible.

Are there some different schools of thought in database design on this point
or something? I had gotten everything that I'd designed so far working in
my tests, I don't see how adding more databases would improve anything at
all. I'd like to know what he might have been thinking of when he said
those things before I meet with him.

If anybody can shed some light on this please let me know.

"Papago" <me (AT) myplace (DOT) com> wrote


I've worked with databases that had several hundred tables, and built
databases with as few as nine tables.

How well or poorly your database is going to work depends on several
factors. If you are using the database to support on line transaction
processing, then departures from normalized form in the critical tables is
going to slow down updates. The slowdown could be enough to be a problem.

If your database courses were good ones, and if you passed them with a C,
then you will recognize at least third normal form.
Look at your tables. Does every table have a primary key? Are primary keys
guaranteed to be present (non null) and unique? Is every non key item
dependent on the key, the whole key, and nothing but the key (so help me
Codd)?

If not, then you may need to justify your design.

If on the other hand, your database has one massive load program that feeds
it new data, and supports OLAP style inquiry most of the time, then design
principles other than normalization could lead you to a satisfactory design
with far fewer tables.
One such design principle is star schema. Did they cover star schemas in
your database courses?

thought in database design on this point or something? <<


Well, in the old days people used to map an existing file to a single
table. The files were often a mess that had everything but the
kitchen sink in them. So a small number of tables was a sign that the
schemaq needed to be normalized.

But this is not a rule or anything like that ... Weird.

"Laconic2" <laconic2 (AT) comcast (DOT) net> wrote

Of course I use primary keys and each table only represents a single entity,
that's the way I was trained.

What are OLAP style inquiries?

"Papago" <me (AT) myplace (DOT) com> wrote



Good. It may turn out that the portion of reality that your database
captures is quite simple, compared to that of e-bay
or of some databases in my experience. It may turn out that the objections
you have heard second hand to your design are spurious.

Best of luck.


I wasn't making a specific reference. It was just a kind of general
reference to the sort of query you tend to find when on line analysis is
going on, as opposed to on line transaction processing.