How far to take normalization? [closed]

Answer 1

DBA's should be concerned if your db is not properly normalized to begin with. After you carefully measured performance and determined you have bottlenecks you may start denormalizing, but I would be extremely cautious.

Answer 2

In the example given indexes set up properly on the tables should allow the joins to occur extremely fast and will scale well to the 100,000s of rows. This is usually the approach that I take to get around the issue.

There are times though that the data is written once and the selected for the rest of its life where it really didn't make sense to do a dozen joins each time.

Answer 3

I'd be most concerned about DBAs who are warning you about the cost of joins, unless you're in a highly pathological situation.

Answer 4

You shouldn't look at denormalizing before you've tried everything else.

Is the performance of this really an issue? Do your database have any features you can use to speed things up without compromising integrity? Can you increase your performance by caching?

Answer 5

Normalize till it hurts, then denormalize till it works

Answer 6

Denormalization has the advantage of fast SELECTs on large queries.

Disadvantages are:

• It takes more coding and time to ensure integrity (which is most important in your case)

• It's slower on DML (INSERT/UPDATE/DELETE)

• It takes more space

As for optimization, you may optimize either for faster querying or for faster DML (as a rule, these two are antagonists).

Optimizing for faster querying often implies duplicating data, be it denormalization, indices, extra tables of whatever.

In case of indices, the RDBMS does it for you, but in case of denormalization, you'll need to code it yourself. What if Department moves to another Office? You'll need to fix it in three tables instead of one.

So, as I can see from the names of your tables, there won't be millions records there. So you'd better normalize your data, it will be simplier to manage.