&quot;1979 (I was one year old then).&quot;Well, we are roughly the same age then. Our is a cynical generation.&quot;One problem is that normal forms are underspecified even by the academy.&quot;The cynic in me would say they were doing their job by the example I gave, which is just to provide easy test answers, after which there wasn&#x27;t much reason to iterate on them. I imagine waiving around normalization forms was a good gig for consultants in the 1980 but I bet even then the real practitioners had a skeptical, arm&#x27;s length relationship with them.

&gt; Someone, somewhere writing down a list and that list being blessed with the imprimatur of Academic Approval (TM)One problem is that normal forms are underspecified even by the academy.E.g., Millist W. Vincent &quot;A corrected 5NF definition for relational database design&quot; (1997) (!) shows that the traditional definition of 5NF was deficient. 5NF was introduced in 1979 (I was one year old then).2NF and 3NF should basically be merged into BCNF, if I understand correctly, and treated like a general case (as per Darwen).Also, the numeric sequence is not very useful because there are at least four non-numeric forms (<a href="https:&#x2F;&#x2F;andreipall.github.io&#x2F;sql&#x2F;database-normalization&#x2F;" rel="nofollow">https:&#x2F;&#x2F;andreipall.github.io&#x2F;sql&#x2F;database-normalization&#x2F;</a>).Also, personally I think that 6NF should be foundational, but that&#x27;s a separate matter.

You can do what you do at the MAC layer without any regard for whether or not it is &quot;OSI layer 2&quot;, or whether your MAC layer &quot;cheats&quot; and has features that extend into layers 1, or 3, or any other layer. Failing to implement something useful because &quot;that&#x27;s not what OSI layer 2 is and this is data layer 2 and the OSI model says not to do that&quot; is silly.To stay on the main topic, same for the &quot;normalization forms&quot;. Do what your database needs.The concepts are just attractive nuisances. They are more likely to hurt someone than to help them.

Why shouldn’t we care about layer 2? You can do really fun and interesting things at the MAC layer.

In a roundabout way this article captures well why I don&#x27;t really like thinking in terms of &quot;normal forms&quot;, especially as a numbered list like that. The key insights are really 1. Avoid redundancy and 2. This may involve synthesizing relationships that don&#x27;t immediately obviously exist from a human perspective. Both of those can be expanded on at quite some length, but I never found much value in the supposedly-blessed intermediate points represented by the nominally numbered &quot;forms&quot;. I don&#x27;t find them useful either for thinking about the problem or for communicating about it.Someone, somewhere writing down a list and that list being blessed with the imprimatur of Academic Approval (TM) doesn&#x27;t mean it is actually useful... sometimes it just means that it made it easy to write multiple choice test questions. (e.g., &quot;What does Layer 2 of the OSI network model represent? A: ... B: ... C: ... D: ...&quot; to which the most appropriate real-world answer is &quot;Who cares?&quot;)

Imperative mood &quot;normalize&quot; assumes that you had something not-normalized before you received that instruction. It&#x27;s not useful when your table design strategy is already normalization-preserving, such as the most basic textbook strategy (a table per anchor, a column per attribute or 1:N link, a 2-column table per M:N link).And this is basically the main point of my critique of 4NF and 5NF. They both traditionally present an unexplained table that is supposed to be normalized. But it&#x27;s not clear where does this original structure come from. Why are its own authors not aware about the (arguably, quite simple) concept of normalization?It&#x27;s like saying that to in order to implement an algorithm you have to remove bugs from its original implementation — where does this implementation come from?The other side of this coin is that lots of real-world design have a lot of denormalized representations that are often reasonably-well engineered.Because of that if you, as a novice, look at a typical production schema, and you have this &quot;thou shalt normalize&quot; instruction, you&#x27;ll be confused.This is my big teaching pet peeve.

what a marvelous motto &lt;3.Certainly a lot more concise than the article or the works the article references.

Normalize till it hurts, then denormalize till it works!

Especially loved the article linked that was dissing down formal definitions of 4NF.

The numbered forms are most useful as a teaching device, not an engineering specification. Once you have internalized 2NF and 3NF violations through a few painful bugs, you start spotting partial and transitive dependencies by feel rather than by running through definitions. The forms gave you the vocabulary. The bugs gave you the instinct..

<a href="https:&#x2F;&#x2F;dl.acm.org&#x2F;doi&#x2F;10.1145&#x2F;2274576.2274589" rel="nofollow">https:&#x2F;&#x2F;dl.acm.org&#x2F;doi&#x2F;10.1145&#x2F;2274576.2274589</a>I&#x27;ll try reading it again.

I have so many questions about that. Should that normal form basically replace 5NF for the purposes of teaching?Why do they hate us and do not provide any illustrative real-life example without using algebraic notation? Is it even possible?I just want to see a CREATE TABLE statement, and some illustrative SELECT statements. The standard examples always give just the dataset, but dataset examples are often ambiguous.&gt; (in its joins)Do you understand what are &quot;its&quot; joins? What is even &quot;it&quot; here.I&#x27;m super frustrated. This paper is 14 years old.

<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Essential_tuple_normal_form" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Essential_tuple_normal_form</a> is cool!Since I had bad memory, I asked the ai to make me a mnemonic:* Every* Table* Needs* Full-keys (in its joins)

It depends on if you are doing OLTP (granular, transactional) vs OLAP (fact&#x2F;date based aggregates) - dates are generally not something you&#x27;d consider in a fully normalized flow to uniqify records.

Frankly I don&#x27;t think that overcounting is solved by normalizing, because it&#x27;s easy to write an overcounting SQL query over perfectly normalized data.I tried to explain the real cause of overcounting in my &quot;Modern Guide to SQL JOINs&quot;:<a href="https:&#x2F;&#x2F;kb.databasedesignbook.com&#x2F;posts&#x2F;sql-joins&#x2F;#understanding-the-problem-of-overcounting" rel="nofollow">https:&#x2F;&#x2F;kb.databasedesignbook.com&#x2F;posts&#x2F;sql-joins&#x2F;#understan...</a>

The lost art of normalizing databases. ”Why is the ARR so high on client X? Oh, we’re counting it 11 times lol”.I would maybe throw in date as an key too. Bad idea?

My brain has been blunted too far due to dynamodb and NoSQL storage usage and now I can’t even normalize anymore

Not OP, but UUID v7 is what you want for most database workloads (other than something like Spanner)

So which normal form do they argue for and against? And what UUID version wins the argument?

I love reading about the normal forms, because it makes me sound like I know what I&#x27;m talking about in the conversation where the backend folks tell me, &quot;if we normalized that data then the database would go down&quot;. This is usually followed by arguments over UUID versions for some reason.

Over time I’ve developed a philosophy of starting roughly around 3NF and adjusting as the project evolves. Usually this means some parts of the db get demoralize and some get further normalized

Typically it&#x27;s better to take normalized data and denormalize for your use case vs. not normalize in the first place. Really depends on your needs

Sometimes the role of your system is to be the authoritative source of data that it has aggregated, validated, and canonicalized.

I&#x27;m a fan of the sushi principle: raw data is better than cooked data.Each process should take data from a golden source and not a pre-aggregated or overly normalized non-authorative source.

One day I hope to write about denormalization, explained explicitly via JOINs.

I adore contiguous reads that ideas like that yield. I&#x27;d rather push that out to a read-only end point, then getting sucked into the entropy of treating what is effectively an unschema-ed blob into editable data.

JSON is extremely fast these days. Gzipped JSON perhaps even more so.I find that JSON blobs up to about 1 megabyte are very reasonable in most scenarios. You are looking at maybe a millisecond of latency overhead in exchange for much denser I&#x2F;O for complex objects. If the system is very write-intensive, I would cap the blobs around 10-100kb.

There are use cases where is better to not normalize the data.

5NF and Database Design