Editing Denormalization (section)

=== DBA implementation ===
With this approach, a database administrator or designer has to denormalize the logical data design. With care this can achieve a similar improvement in query response, but at a cost — it is now the database designer's responsibility to ensure that the denormalized database does not become inconsistent. This is done by creating rules in the database called ''[[Constraint satisfaction|constraints]]'', that specify how the redundant copies of information must be kept synchronized, which may easily make the de-normalization procedure pointless. It is the increase in logical [[Complexity of constraint satisfaction|complexity]] of the database design and the added complexity of the additional constraints that make this approach hazardous. Moreover, constraints introduce a [[trade-off]], speeding up reads (<code>SELECT</code> in SQL) while slowing down writes (<code>INSERT</code>, <code>UPDATE</code>, and <code>DELETE</code>). This means a denormalized database under heavy write load may offer ''worse'' performance than its functionally equivalent normalized counterpart.