4 ms·

> Normalize your data unless you have a good reason not to Ouch. You don't want to just say that and move on. The author even linked to a page citing 10 diffe

> Normalize your data unless you have a good reason not to Ouch. You don't want to just say that and move on. The author even linked to a page citing 10 different kinds of normalization (11 with the "non-normalized"). Most people don't even know what those are, and have no use for 7 of those. Do not send people on wild-goose chases after those higher normal forms.

pavel_lishin 2y ago
But the author did have a paragraph explaining, in general, what they mean. And they're right! I've had to fix a few issues of this in a project I recently got moved to. There's almost never a reason to duplicate data.
- deleted 2y ago
  [deleted]
hobs 2y ago
I guess this is targeted towards noobs, but the answer is pretty much always 3rd normal form if you are clicking this and are not sure.
- makr17 2y ago
  Interesting, I would have said Boyce-Codd unless you have a good reason to vary in either direction.
  - philipwhiuk 2y ago
    The problem with BCNF is generally that you're enforcing a generally fairly complex and subject-to-change relation at database level rather than application logic.
cryptonector 2y ago
The general rule is to normalize to the max, then denormalize till you get the performance that you need.
- jayknight 2y ago
  Anyone here use 6NF to avoid nulls? See https://36chambers.wordpress.com/2021/10/22/avoiding-null-with-normalization/ https://36chambers.wordpress.com/2021/10/22/avoiding-null-wi...
  - cryptonector 2y ago
    Isn't 6NF essentially a flavor of EAV? I think essentially it is. 6NF means having one non-PK column, so that if the value would be NULL then the row need not exist, and so the value column can be NOT NULL. But when you need all the columns of what you'd think of as the <thing> then you need to go gather them from all those rows in all those tables. It's a bit annoying. On the other hand a proper EAV schema has its positives (though also its negatives).
    - jayknight 2y ago
      It's similar, but instead of one table holding lots of attributes, there are separate tables that hold optional fields that might otherwise be null if they were in the main table.
  - magicalhippo 2y ago
    Every time I see a suggestion like this, I wonder what kind of projects people work on that only require a few columns. In my experience every non-trivial project would need several dozen columns in core tables, all which could be NULL while the user works on the record during the day. In our current project we'd have to do several hundred joins to get a single main-table record. I also wonder why people have such an aversion for NULL. Crappy tools?
    - jayknight 2y ago

pavel_lishin 2y ago

But the author did have a paragraph explaining, in general, what they mean. And they're right! I've had to fix a few issues of this in a project I recently got moved to. There's almost never a reason to duplicate data.

deleted 2y ago
[deleted]

hobs 2y ago

I guess this is targeted towards noobs, but the answer is pretty much always 3rd normal form if you are clicking this and are not sure.

makr17 2y ago
Interesting, I would have said Boyce-Codd unless you have a good reason to vary in either direction.
- philipwhiuk 2y ago
  The problem with BCNF is generally that you're enforcing a generally fairly complex and subject-to-change relation at database level rather than application logic.

cryptonector 2y ago

The general rule is to normalize to the max, then denormalize till you get the performance that you need.

jayknight 2y ago
Anyone here use 6NF to avoid nulls? See https://36chambers.wordpress.com/2021/10/22/avoiding-null-with-normalization/ https://36chambers.wordpress.com/2021/10/22/avoiding-null-wi...
- cryptonector 2y ago
  Isn't 6NF essentially a flavor of EAV? I think essentially it is. 6NF means having one non-PK column, so that if the value would be NULL then the row need not exist, and so the value column can be NOT NULL. But when you need all the columns of what you'd think of as the <thing> then you need to go gather them from all those rows in all those tables. It's a bit annoying. On the other hand a proper EAV schema has its positives (though also its negatives).
  - jayknight 2y ago
    It's similar, but instead of one table holding lots of attributes, there are separate tables that hold optional fields that might otherwise be null if they were in the main table.
- magicalhippo 2y ago
  Every time I see a suggestion like this, I wonder what kind of projects people work on that only require a few columns. In my experience every non-trivial project would need several dozen columns in core tables, all which could be NULL while the user works on the record during the day. In our current project we'd have to do several hundred joins to get a single main-table record. I also wonder why people have such an aversion for NULL. Crappy tools?
  - jayknight 2y ago