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).
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.
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?
No, it's just a dedication to pure relational algebra. Nulls introduce "three valued logic" into your code/sql. A nullable boolean column can contain 3 different "values" instead of two. True is not false, true is not null, false is not null (and null is neither true nor false). Or in a nullable numeric field, you have rows where that column is neither greater than zero or less than zero.
On the other hand, even if you eliminate all nulls, you still have to do some three-valued logic ("A join B on B.is_something", "A join B on not B.is_something" and the "anti-join": "A where no B exists"), but only in the context of joins.
It feels a little like rust's Option type. If something in "nullable", these are tools that forces you to deal with it in some way so there are fewer surprises.
