Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

5NF and Database Design

kb.databasedesignbook.com

Post reply on HN
Print view View original

21–30 of 86 posts

Re: 5NF and Database Design

#21

Post by wolttam »

jerf wrote: post #14

In 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…

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

Re: 5NF and Database Design

#22

Post by skeeter2020 »

jghn wrote: post #12
andrew_lettuce wrote: post #6

Earlier quoted context omitted.

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

>> Usually this means some parts of the db get demoralize

I largely agree with your practical approach, but try and keep the data excited about the process, sell the "new use cases for the same data!" angle :)

Re: 5NF and Database Design

#24

Post by tossandthrow »

Tostino wrote: post #4
necovek wrote: post #3

Earlier 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)

I use the null uuid as primary key - never had any DB scaling issues.

Re: 5NF and Database Design

#25

Post by jerf »

wolttam wrote: post #21
jerf wrote: post #14

In 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…

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

You can do what you do at the MAC layer without any regard for whether or not it is "OSI layer 2", or whether your MAC layer "cheats" and has features that extend into layers 1, or 3, or any other layer. Failing to implement something useful because "that's not what OSI layer 2 is and this is data layer 2 and the OSI model says not to do that" is silly.

To stay on the main topic, same for the "normalization forms". Do what your database needs.

The concepts are just attractive nuisances. They are more likely to hurt someone than to help them.

Re: 5NF and Database Design

#26

Post by petalmind »

tossandthrow wrote: post #24
Tostino wrote: post #4

Earlier quoted context omitted.

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

I use the null uuid as primary key - never had any DB scaling issues.

Yeah, no NULL is ever equal to any other NULL, so they are basically unique.

Re: 5NF and Database Design

#27

Post by necovek »

tadfisher wrote: post #8
necovek wrote: post #3

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.

This was an attempt to extend jokes and not ask for explanation: there are a number of normal forms, and people usually talk about "normalization" without being specific thus conflating all of them; out of 7 UUID versions, only 2 generally make sense for use today depending on whether you need time-incrementing version or not.

Re: 5NF and Database Design

#30

Post by Groxx »

petalmind wrote: post #26
tossandthrow wrote: post #24

Earlier quoted context omitted.

I use the null uuid as primary key - never had any DB scaling issues.

Yeah, no NULL is ever equal to any other NULL, so they are basically unique.

You are also guaranteed to be able to retrieve your data, just query for '... is null'. No complicated logic needed!
Post reply on HN