Coding Horror: Maybe Normalizing Isn't Normal

En Coding Horror: Maybe Normalizing Isn't Normal planten el eterno debate entre la normalizacion y la des-normalizacion (que no es lo mismo que no normalizar).

One of the items we're struggling with now on Stack Overflow is how to maintain near-instantaneous performance levels in a relational database as the amount of data increases. More specifically, how to scale our tagging system. Traditional database design principles tell you that well-designed databases are always normalized, but I'm not so sure.

y plantea un caso donde puede justificarse trabajar con datos desnormalizados...

En The Mother of All Database Normalization Debates on Coding Horror | High Scalability
hay algunas de las frases sacadas de los comentarios que estan buenas...

• Normalize until it hurts, denormalize until it works. (Jeff)
• Use materialized views which are tables created and maintained by your RDBMS. So a materialized view will act exactly like a de-normalized table would - except you keep you original normalized structure and any change to original data will propagate to the view automatically. (Goran)
• Denormalization is something that should only be attempted as an optimization when EVERYTHING else has failed. Denormalization brings with it it's own set of problems. You have to deal with the increased set of writes to the system (which increases your I/O costs), you have to make changes in multiple places when data changes (which means either taking giant locks - ugh or accepting that there might be temporary or permanent data integrity issues) and so on. (Dare Obasanjo)
• You can read fast and store slow or you can store fast and read slow. The biggest performance killer is so called physical read. Finding and accessing data on disk is the slowest operation. Unless child table is clustered indexed and you're using the cluster index in the join you will be making lots of small random access reads on the disk to find and access the child table data. This will be slow. (Goran)
• The biggest scalability problems I face are with human processes, not computer processes. (John)
• Don't forget that the fastest database query is the one that doesn't happen, i.e. caching is your friend. (Chris)
• Normalization is about design, denormalization is about optimization. (Peter Becker)
• Speaking from long experience, if you don't normalize, you will have duplicates. If you don't have data constraints, you will have invalid data. If you don't have database relational integrity, you will have orphan "child" records, etc. Everybody says "we rely on the application to maintain that", and it never, never does. (A. Lloyd Flanagan)
• What I think is funny is the number of people who think that because they use LINQ or Hibernate they aren't affected by these issues. (Sam)
• Multiple queries will hurt performance much less than the multi-join monstrosity above that will return indistinct and useless data. (Chris)
• Cache the generated view pages first. Then cache the data. You have to think about your content- very infrequently will anyone be updating it, it's all inserts. So you don't have to worry about normalization too much. (Matt)
• Don't fear normalization. Embrace it. (Charles)
• It might be possible to overdo it, but trust me, I have had 20 times the problems with denormalized data than with normalized. (PRMAN)
• IOW, scalability is not a problem, until it is. Strip away the scatalogical reference, and all you have is a boring truism. (Yawn)
• Is my Site OLTP? If the answer is yes then Normalize. Is my site OLAP? If the answer is yes then De-Normalize! (WeAreJimbo)
• Be careful not to confuse a denormalised database with a non-normalised database. The former exists because a previously normailsed database needed to be 'optimised' in some way. The latter exists because it was 'designed' that way from scratch. The difference is subtle, but important. (Bob)

La negritas son agregados mios...