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

By: Memo: Avoid Functions in Database Queries | Down Home Country Coding With Scott Selikoff and Jeanne Boyarsky

Thu, 21 Oct 2010 06:19:49 +0000

[...] although since reads are more common than writes, this is often easy in practice. I am aware some developers have issues with denormalized data, but it is often necessary on large tables with queries that can run for minutes or even [...]

By: ARH95

ARH95 — Fri, 15 Oct 2010 21:18:21 +0000

Fabulous article. I’m dealing with overnormalization right now, in an IT computer database. Normalizing, in this case, is just more work than it’s worth, especially for a small company.

I mean, I’ve got a table for CPUType and three entries for a P5. I will NEVER buy another P5. They don’t make them. I don’t don’t want one… you get the picture, I hope.

I am in the process of “denormalizing,” to a degree… but I will admit it HURTS because normalizing as been so drilled in to my brain.

By: Kevin

Kevin — Mon, 30 Aug 2010 23:36:15 +0000

An old topic, but still ranks in Google, so I’ll still comment.

I think you need to also consider disk latency when assessing the cost of disk space. It might be cheap per GB of storage, but if the database manager needs to bring in four times as many pages in order to perform a join or any other operation on the table, then that could have a very negative impact on performance. There’s usually more disk storage than memory allocated to a database.

Also, the sophistication of the database manager in generating access paths and the accuracy of database statistics will play a large part in determining whether it’s faster to denormalise to plain text, or use lookup tables (as per your ‘country’ field example.

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*