Denormalization 101

I have had exactly two conversations this week about denormalization, which is a sign that it is time to write a blog post. If you already know what denormalization is, you will likely find this blog post uninteresting. That is okay! It is meant more to be an artifact that I can point to when people who haven't been burnt by the fires of sad databases (or, perhaps, sad ETL pipelines) ask what I'm talking about. The well-behaved schema Imagine the data behind an art gallery. Galleries run calls — open invitations for submissions — and artists submit entries. The application that captures all this stores it the way Codd would want: tidy, normalized, every fact in exactly one place. GalleryPKidintnamestringurlstringstatestringCallPKidintFKgallery_idinttitlestringdeadlinedateEntryPKidintFKcall_idintFKartist_idinttitlestringArtistPKidintnamestringemailstringstatestring Here's what a handful of rows actually look like — the keys (gallery_id, call_id, artist_id) are the threads you pull to…