A common case of denormalization is storing the count or sum of the "many" objects in a one-to-many relationship? as an attribute of the "one" entity.
For instance, the Everything2 system stores the number of cools that a writeup has received in the writeup table, when a simple SQL select count on the coolwriteups table can retrieve that information.
E2 also stores the number of writeups that a user has created in the user variables when you can do a select count on node join writeup to calculate that.
Database designers often justify denormalization on [performance issues]?, but they should note that logical denormalization can easily break the consistency of the database, one of the all-important ACID properties.
However, a designer can achieve the performance benefits while retaining consistency by performing denormalization at a physical level:
create an indexed view? on the tables in which you are interested, and the database management system will physically denormalize the data into the index for faster select queries on the view,
but every time a user inserts, updates, or deletes something in the table, the DBMS will automatically update all views and indexes.
See also database normalization.
Source: [Denormalization@Everything2.com]
/Talk?
![[Home]](wikipedia.png)