Maybe Normalizing Isn't Normal

Very Nice post, quiet informative.
Database designing problems being the buzzwords these days, one of the most common designing mistakes is the “Poor Planning / Architecture” of the database or mart. Follow the link to know more…
http://www.sqllion.com/2010/08/database-design-and-modeling-i/

Interesting post. I’ll assume it’s from a programmer’s perspective.

After many years of struggling with, and correcting the problems from very bad database designs, I’ve started compiling all the design and architecture mistakes into a blog.

In my first post, I compare DB design to the foundation of a house, and the Leaning Tower of Pisa.
http://rodgersnotes.wordpress.com/2010/09/14/database-design-mistakes-to-avoid/

I make the point that a good database model eliminates thousands of lines of code.
Not cause or require thousands of lines of code to make it work.
Also, that unlike programs, DB designs are rarely refined or rewritten.

There are a whole bunch of other mistakes listed in the category:
http://rodgersnotes.wordpress.com/category/database-design-mistakes-to-avoid/

Unfortuately all the mistakes I’ve seen don’t fall into the teachings of 3NF, BCNF, 5NF, etc.

I haven’t written about denormalization yet. But denormalization implies that you have already normalized.

As for the question on views and performance, see the database tuning presentation, which has been circulating around the world.
There is also another presentation on cartesian products in SQL queries, which I’ve discovered are far too common.

Hope it’s useful.

300 replies, and just 3 voting for caching, that tells you what the top 1% would do.

Is not hard to trigger updates on a denormalized storage engine(couchdb, memcache, mongodb- this is probably the only place where mongo could be useful btw) for time sensitive parts of your application, and you won’t need to do that for every table just for the ones that need it.

Isn’t the normalized example model already denormalized to some degree?
Because if it would be more normalized, there would be no separate “id” fields, if a unique key can be created with existing fields, right?