At that point why not abandon databases entirely and use a key-value store?
The answer, obviously, is because traditional tables make lots of things really easy. SQL is designed for that use case, and it's performant.
You're not even talking about traditional relational databases anymore. You're trying to construct tables inside of tables, which means abandoning performance, indexes, etc.
> At that point why not abandon databases entirely and use a key-value store?
Because there is a schema, it's just a dynamically evolving one, and also, presumably the rest of your system depends on the relational DB, so why multiply your dependencies unnecessarily?
> You're not even talking about traditional relational databases anymore.
There's nothing non-relational about the schema I've outlined, it matches what the domain requires with less noise than 400 nullable columns.
The answer, obviously, is because traditional tables make lots of things really easy. SQL is designed for that use case, and it's performant.
You're not even talking about traditional relational databases anymore. You're trying to construct tables inside of tables, which means abandoning performance, indexes, etc.