Earlier quoted context omitted.
So which normal form do they argue for and against? And what UUID version wins the argument?
Explaining jokes is poor form.
On the internet it is normal.
5NF and Database Design
11–20 of 86 posts
Re: 5NF and Database Design
#12There are use cases where is better to not normalize the data.
Typically it's better to take normalized data and denormalize for your use case vs. not normalize in the first place. Really depends on your needs
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
Re: 5NF and Database Design
#13There are use cases where is better to not normalize the data.
I'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.
Re: 5NF and Database Design
#14In a roundabout way this article captures well why I don't really like thinking in terms of "normal forms", especially as a numbered list like that. The key insights are really 1. Avoid redundancy and 2. This may involve synthesizing relationships that don'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 "forms". I don'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't mean it is actually useful... sometimes it just means that it made it easy to write multiple choice test questions. (e.g., "What does Layer 2 of the OSI network model represent? A: ... B: ... C: ... D: ..." to which the most appropriate real-world answer is "Who cares?")
Re: 5NF and Database Design
#15In a roundabout way this article captures well why I don't really like thinking in terms of "normal forms", especially as a numbered list like that. The key insights are really 1. Avoid redundancy and 2. This may involve synthesizing relationships that don'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-bless…
> 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 "A corrected 5NF definition for relational database design" (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 (https://andreipall.github.io/sql/database-normalization/).
Also, personally I think that 6NF should be foundational, but that's a separate matter.
Re: 5NF and Database Design
#16In a roundabout way this article captures well why I don't really like thinking in terms of "normal forms", especially as a numbered list like that. The key insights are really 1. Avoid redundancy and 2. This may involve synthesizing relationships that don'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-bless…
> 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 "A corrected 5NF definition for relational database design" (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 bas…
"1979 (I was one year old then)."
Well, we are roughly the same age then. Our is a cynical generation.
"One problem is that normal forms are underspecified even by the academy."
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'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's length relationship with them.
Re: 5NF and Database Design
#17There are use cases where is better to not normalize the data.
I'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.
Sometimes the role of your system is to be the authoritative source of data that it has aggregated, validated, and canonicalized.
Re: 5NF and Database Design
#18love this
Re: 5NF and Database Design
#19There are use cases where is better to not normalize the 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/O for complex objects. If the system is very write-intensive, I would cap the blobs around 10-100kb.
Re: 5NF and Database Design
#20Earlier quoted context omitted.
I'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.
Sometimes the role of your system is to be the authoritative source of data that it has aggregated, validated, and canonicalized.
This is great. Then I would consider the aggreated, validated, and canonicalized source as a Golden Source. Where I've seen issues is that someone starts to query from a nonauthoritative source because they know about it, instead of going upstream to a proper source.