views:

85

answers:

4

Two of my colleagues and I are building a system to do all sorts of hydrology and related stuff. It has a lot of requirements and have a good number of tables.

We are handling all sorts of sampling that it is done within this scope (hydrology) and we are trying to figure out a way to do it in a less painful way.

Sometimes we need to get all that sampling together and I'm starting to think we are over-complicating our database design.

How or when do you know that you are over-designing a database? Of course we are considering a lot of Normal Form Rules and other good practices, but when it is OK to drop one of those rules, e.g. not normalizing something?

What are your opinions on this?

A: 

We have a system with literally hundreds of tables - its no big deal, its just that a lot of different things are stored in the database.

Kragen
Humn, but what about complexity? We are working with a lot of related tables, for example: we have a monitoring point table, a instruments table (1:m with monitoring point) and n tables that references instruments. That kind of thing repeats itself on the project. Are we doing it wrong? Is there any better way?Please, note that these are not repeated.
George
@George: You should ask these kinds of things in another question; not in a comment. Show us your schema and ask for feedback.
hobodave
But please, only a few tables
Jens Schauder
I'm sorry, can't provide a schema. Really sorry, I know that WOULD be helpful.
George
+4  A: 

Short Answer

You can't, worry about something else.

Long Answer

This sounds like yet another form of premature optimization. (YAFPO?)

You should design your schema using third normal form (3NF). Once designed, you should populate your tables with data and begin profiling.

If a particular query is deemed too costly then you should look into denormalization on a case by case basis.

Technical Answer (for the nitpickers who will inevitably object to: "you can't")

You will reach a limit at some point based on your choice of RDBMS and/or storage engine. Likely ceilings will be memory consumption or open file descriptors.

hobodave
The expensive queries cuold be attacked by different means: denormalization, views, materialized views, checking indexes, checking if the indexes are in a different tablespace,...
Alfabravo
@Alfabravo: You are correct. I did not intend to convey that denormalization was the _only_ option available. I was instead limiting the scope of my answer to address the "many tables" fear.
hobodave
Right, you are correct as well, anyway :)BTW: for our fearful friend, right now I'm working on some freaky EJBs done by a bunch of monkeys which use about... let me do the math... 1600 tables. So, buy a flask full of vitamins and kill'em! (not literally)
Alfabravo
ouch! i think we don't have THAT much. It will reach the hundreds (a low hundreds), but not more...
George
A: 

We have a ton of tables in our system as well. What we did was normalize the database to a good point, then created a few views that encompass the most common table usage needs of our system. Something like that could help you as well.

Tom
A: 

"When do you have too many tables?"

At the level of logical design, the correct answer is "never".

At the level of physical design (insofar as "having a table" really refers to some concept that pertains to the physical design), the correct answer is "if and when the queries that you need to do, given the restrictions of the DBMS you are using, are causing performance to be unacceptably low.".

Erwin Smout