liveBook · Manning

Denormalization

As explained in Grokking Relational Database Design

Denormalization is the deliberate introduction of controlled redundancy or less-normalized database structures to improve performance or meet operational needs.

Denormalized data deliberately introduces controlled redundancy or less-normalized relationships to make frequent queries faster. It is a rare, last-resort optimization used when joins across several tables consume significant time, resources, or money. section 7.12 section 7.14

Use a careful two-step decision process:

  • Identify frequent queries that join more than two tables and verify that they cause meaningful performance or cost problems. section 7.12
  • Duplicate selected columns or restore a direct relationship so the query joins fewer tables. section 7.12
  • Compare the performance benefit with the risks of inconsistent inserts, updates, and deletes. section 7.13 section 7.14

Music app: removing an unnecessary join

A normalized music database connects artists to songs through albums. Finding an artist’s top songs therefore joins artist, album, and song, even though album contributes no output data. Adding artist_id to song creates a direct artist–song relationship, allowing the query to join only artist and song. The change improves responsiveness but duplicates relationship information that must remain synchronized. section 7.12

Online store: restoring a direct relationship

Receipt queries may join user, payment_method, and purchase even though payment_method contributes little output. Restoring a direct user–purchase relationship simplifies the query, but introduces redundancy and violates BCNF. A stable email policy and account-only purchases reduce the risk of insertion and deletion anomalies, yet the change still requires a cost-and-benefit review. section 7.13

-- comment: works for MySQL, MariaDB, 
-- comment: and PostgreSQL
-- comment: consult ChatGPT on adaptations 
-- comment: for other RDBMS
SELECT artist.artist_name, song.song_title
 FROM artist
 INNER JOIN album 
   ON artist.artist_id = album.artist_id
 INNER JOIN song 
   ON album.album_id = song.album_id
 WHERE artist.artist_name = 'Nebula Nova'
 ORDER BY album.album_id, song.song_id
 LIMIT 5;

Compare the original three-table query with the shorter denormalized form in the related listing. section 7.12

How Grokking Relational Database Design covers it

How deep it goes
Explains definition, decision steps, schema changes, query effects, and data-anomaly trade-offs, but stops short of implementation synchronization details.
Examples
Uses artist–album–song queries and user–payment_method–purchase receipt queries to demonstrate reduced joins and redundancy.
What it assumes
Assumes familiarity with normalized relational designs, table relationships, joins, foreign keys, and BCNF.
What you can do after
Evaluate and apply denormalization by identifying costly joins, adding selective redundancy, and checking data-change anomalies.
How it connects
Connects denormalization with database normalization, query performance, database indexing, BCNF, transitive dependency, and data anomalies.

Also explained in

Compare how 6 books explain denormalization →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Grokking Relational Database Design. The section links point to the parts of the book it draws on.