Therefore, when studying normalization, one should consider it a spectrum. On the right we can have full normalization. On the left we can have full denormalization. Between the two are levels, or forms rather, of denormalization and normalization. With denormalization, the benefits are that you reduce the complexity of tables and table designs, potentially reduce time for the development process, and increase record reading performance, and sometimes dramatically. The costs are that you increase integrity problems unless handled in your application layer of your software (outside the data layer), and you increase table and database size.

So why use one or the other? Well, if you wish to do heavy reporting, which means heavy record reading, then obviously a lot of SQL JOINs to get the data you need is going to be slow. This is where denormalization can benefit the database design, reducing the numbers of JOINs necessary. Likewise, if you do heavy writing, then a normalized database means less writes and therefore is going to be faster than a denormalized database. And if you do a mix of reads and writes on a given set of tables, then the table design would likely work better right of center with the first or second normal form, unless after a performance checkup you realize you might have a need for a few tables to be more denormalized than that.

In large enterprise applications, they often find it suitable to interact with 3 databases: data entry, production, and reporting. In the data entry database, it is heavily normalized and has a heavy load of record writing. In the reporting database, it is heavily denormalized and has a heavy load of record reading. In the production database, it is normalized to like first or second form, perhaps more in some tables, or less in others. The data entry tables are where records going into the database originate before they are validated and authorized to be written to the production database. The production database has all the current items and are often used to pull records for the screens used by most of the business needs except for larger reports. And then there’s the reporting database, which usually has one hour old or up to one day old data and is used for running larger reports. A set of replication jobs move data between the databases according to rules.

With the data entry database, often companies find it suitable to move the records into a message queue because during outages they may still need to answer those calls and it might be easier with a message queue to move those calls to another location. And with the production and reporting databases, these are often a traditional database, not a message queue. However, the next step would then be to take the reporting database and to section of data such into isolated server clusters, or data marts, dedicated either to company name, customer type, or some other kind of categorization that increases fault tolerance and improves system performance.