Comments on: Why too much Database Normalization can be a Bad Thing

By: scott

scott — Sun, 23 Nov 2008 08:39:21 +0000

Great Raditya, why create a chart as a project and I’ll post the results.

By: scott

scott — Sun, 23 Nov 2008 08:38:43 +0000

I think a lot of you are taking me too literally… I never said get rid of normalization, but its clear that too much of it can be a bad thing. In general, reads within a denormalized system is almost always faster than a normalized one, the catch is updating and data storage are poor.

By: Raditya Arthapraja

Raditya Arthapraja — Fri, 21 Nov 2008 17:30:25 +0000

Great, article!

How about a performance chart comparing the database that stores the same information; but, with the first database being normalized too much, the second database being not too normalized, and the third being not normalized?

By: Daoud AbdelMonem Faleh

Daoud AbdelMonem Faleh — Thu, 20 Nov 2008 20:58:05 +0000

I once eliminated all FK relationships from the database and managed them in the code. It was more error prone yes, it took more time to implement yes, but it was a huge gain in performance. I’ve gone that way cause denormalisation was not an option as some of those tables were shared between many entities and updates were frequent on them. The key to success down this road was to test test test…

By: Joachim

Joachim — Thu, 20 Nov 2008 19:09:58 +0000

Great. So true !
This is one of the amazing aspects where the conclusion is so clear and easy to take up – but most developers don’t ask that question. 3NF is holy, if you don’t normalize till it hurts you’re a bad developer and you’ll be contracted by an awful disease soon .
Good to read that someone has the ba… to have an own opinion.
Thanks !

By: Mike

Mike — Thu, 20 Nov 2008 15:36:52 +0000

It is true that joins have a cost, but the cost is primarily in CPU. The cost of denormalizing is in disk. Now it is true that disk is cheap, but CPU performance has improved more dramatically in recent years, more so than disk speed. (In fact the increase of disk capacity may have reduced the performance of many disk systems in practice, because a wider RAID array with more spindles is no longer necessary from a space point of view). From a performance point of view, disk is still orders of magnitude slower than memory.

I tested the countries example in MS SQL Server. At 10,000 rows there was not much difference, but by 160,000 rows there were clearly fewer logical reads in the normalized model.

By: Lars Hoss

Lars Hoss — Thu, 20 Nov 2008 12:42:55 +0000

I agree that too much normalization can have negative impacts for read performance. But it helps to reduce redundancy and maintain integrity. Quite often it also depends on the database you are using. Almost every MySQL developer will tell you that joins suck and you better use denormalized tables for best speed. Things are different for PostgreSQL or even Oracle, though. And things like Materialized Views can help to improve read performance as well.
Some days ago I had to “fix” a table from someone who thinks that normalization is bad. This table has 80 columns. Columns like cost_age30, cost_age31, cost_age32 …
Now imaging how queries do look like on those tables *sigh*

By: Milos Misic

Milos Misic — Thu, 20 Nov 2008 11:58:56 +0000

Nice article, I’m no db-expert but I agree with the point you made about too much normalization though your example with country table and USA as an example isn’t that good. For instance I am from Serbia and this country has changed its name several times, from ‘Yugoslavia’; ‘Serbia and Montenegro’ to only ‘Serbia’. So even country table isn’t ’static’ as you wrote.