Pattern: Controlled Redundancy



Controlled Redundancy is a technique to use redundant fields in a physical database in order to speed up reading database access.


In the process of optimizing the order processing system you find out that clerks often produce a test invoice and check it at the screen before they confirm orders. They complain to you that this use case could be handled faster. From database trace protocols you find out that the queries for printing orders produce heavy database load.

You did denormalize the Order table. But for a normal invoice with five positions you still have 7 databases accesses. One for the order and its positions, one for the customers data and 5 primary key accesses for the article data needed for five order positions. You consider this unacceptable.


How can you manage to read physical views with a single page database access when you need to read data from a parent entity?



The forces involved here are the same as in the Denormalization pattern.


Replicate those parts of the parent entity (Article) in the child entity (OrderItem) that you need for the use case. Replicate only stable data that are not subject to frequent updates.



Controlled Redundancy should only be used for stable data. An article name will seldom change during the live span of an order. Redundant customer data like the customer’s name will also seldom change. It is acceptable to replicate such data. If it comes to an article price we may well start a discussion. If the price is fixed during the live span of the order, you will replicate it. If the price is subject to frequent updates you should consider the read / update performance tradeoff.

Related Patterns

NarrowViews will motivate you to replicate only the data you really need for high performance use cases.