There are use cases where is better to not normalize the data.
One day I hope to write about denormalization, explained explicitly via JOINs.
Please do, you content is great!
5NF and Database Design
31–40 of 86 posts
Re: 5NF and Database Design
#32Normalize till it hurts, then denormalize till it works!
what a marvelous motto Certainly a lot more concise than the article or the works the article references.
Re: 5NF and Database Design
#33Earlier quoted context omitted.
So which normal form do they argue for and against? And what UUID version wins the argument?
Not OP, but UUID v7 is what you want for most database workloads (other than something like Spanner)
Me still using bigints... Which haven't given me any problems. Wouldn't use it for client generated IDs but that is not what most applications require anyway.
Re: 5NF and Database Design
#34There 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.
I adore contiguous reads that ideas like that yield. I'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.
Re: 5NF and Database Design
#35Normalize till it hurts, then denormalize till it works!
what a marvelous motto Certainly a lot more concise than the article or the works the article references.
Imperative mood "normalize" assumes that you had something not-normalized before you received that instruction. It'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'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'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 "thou shalt normalize" instruction, you'll be confused.
This is my big teaching pet peeve.
Re: 5NF and Database Design
#36Earlier quoted context omitted.
what a marvelous motto Certainly a lot more concise than the article or the works the article references.
Imperative mood "normalize" assumes that you had something not-normalized before you received that instruction. It'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 p…
> But it'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?
I find the bafflement expressed in the article as well as the one linked extremely attractive. It made both a joy to read.
Were I to hazard a guess: Might it be a consequence of lack of disk space in those early decades, resulting into developers being cautious about defining new tables and failing to rationalise that the duplication in their tragic designs would result in more space wasted?
> 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.
Agreed, but as the OP comment stated they usually started out normalised and then pushed out denormalised representations for nice contiguous reads.
As a victim of maintaining a stack on top of an EAV schema once upon a time, I have great appreciation for contiguous reads.
Re: 5NF and Database Design
#37My brain has been blunted too far due to dynamodb and NoSQL storage usage and now I can’t even normalize anymore
Re: 5NF and Database Design
#38https://en.wikipedia.org/wiki/Essential_tuple_normal_form is cool! Since I had bad memory, I asked the ai to make me a mnemonic: * Every * Table * Needs * Full-keys (in its joins)
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.
> (in its joins)
Do you understand what are "its" joins? What is even "it" here.
I'm super frustrated. This paper is 14 years old.
Re: 5NF and Database Design
#39Earlier quoted context omitted.
Imperative mood "normalize" assumes that you had something not-normalized before you received that instruction. It'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 p…
> But it'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? I find the bafflement expressed in the article as well as the one linked extremely attractive. It made both a joy to read. Were I to hazard a guess: Might it be a consequence of lack of disk space in those early decades, resulting into developers being cauti…
> Might it be a consequence of lack of disk space in those early decades
A plausible explanation of "normalization as a process" was actually found in https://www.cargocultcode.com/normalization-is-not-a-process... ("So where did it begin?").
I hope someday to find some technical report of migrating to the relational database, from around that time.
Re: 5NF and Database Design
#40The 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..