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

By: Napar Forguxol

Napar Forguxol — Sat, 14 Aug 2021 17:00:36 +0000

I think that people too much normalization-aware might be sick and design worse databases, less “browsable” and harder to code with.
Space isn’t an issue in most cases, and I think this: if you have values which can be naturally primary keys, use them! DO NOT create another id just because it is “shorter”. I believe PK should be the actual values, not something that “stands for”, just because you spare bytes. E.g.: if you have a customer_table, let the PK be the actual customer_id, not some sequence generated id which then you will be using around for FKs.

By: Philip Thomas

Philip Thomas — Tue, 11 Feb 2020 11:36:41 +0000

SQL Server 2016’s temporal table functionality can really eat into disk space if tables are not normalised. The convenience of history logging across multiple tables has lent me to over-normalise thus avoiding history tables duplicating wide rows in entirety for each minor data update. I realise that this functionality was not available during the OP (for SQL Server, at least), but the requirement to keep a change history was. If the native functionality didn’t exist, for whatever platform, it would be written for purpose. Change history is easier when over-normalising.

By: Paulo

Paulo — Thu, 23 May 2019 19:58:12 +0000

It seems some people didn’t read the word “too much”.

By: john

john — Tue, 08 Oct 2013 00:03:42 +0000

I’m poking around SQL Server 2012 with the Adventureworks database. So sick of all these numeric ids!!!

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?