Here’s a good example of 1:1 denormalization: Say I’m running a music streaming service. I can store my music tracks as a giant database of MP3s, ID3 tags inclu

Here’s a good example of 1:1 denormalization: Say I’m running a music streaming service. I can store my music tracks as a giant database of MP3s, ID3 tags included, and parse out each ID3 tag on each read. I could, alternatively, store the music tracks as a giant database of music tracks, which has “Artist”, “Album”, etc. fields, and one field for “MP3” that contains no id3 tags. Both are “normalized” data structures. Storing the id3 tags with the MP3 would be denormalization. It might be much saner to do that than to reconstruct them every time someone goes to download them. For performance, though - You want to store the MP3s in their own table, or not even in a “table” but as a blobstore. Storing the MP3 files for your tracks inline is entirely feasible. 3-10MB inline blobs will work in your modern database engine of choice, and simplify a lot - But you’ll often want to write your presentation layer with “SELECT * FROM tracks” - And you can do that if you just store the data blob separately; i.e. denormalize. If you have hundreds of fields on a record, selecting from the subset that are actually relevant is far, far saner. Particularly when a large group can be nullable, and will likely be nullable together. If 10% of your business is washers - Washers of every shape, thickness, hole-size, material, etc. - You will have all of those attributes in your parts database. It’s best to treat those as first-class citizens, but they belong in a nullable 1:1 relationship.