When to Denormalize

Denormalization is a legitimate technique and a terrible default.

It is legitimate when you have measured a real performance problem, the join is genuinely the cause, and you have a plan for keeping the copy correct: a trigger, a scheduled job, or accepting staleness deliberately and saying how stale.

It is a problem when it happens by accident, which is what the flat table above is.

The honest ordering. Normalize first. Measure. Denormalize the specific thing the measurement pointed at, and write down how the copy stays correct.

A denormalized column with no answer to 'what updates this' is a column that will be wrong within the year.

◈ Graded Query

Show the cost of the broken design. From the flat signups table, return each distinct venue name with how many signup rows mention it, ordered by name. The result will show one real venue appearing as two, which is the point.

Checked against the rows your query returns. 1 visible and 2 hidden checks, some against data you cannot see.

loading editor…

Mark this lesson complete

Signed in, your progress follows you to every device.

Next: Practice Test →
← Back