Reduced column bloat, easy reusability, easy reporting and data extraction, ease of bulk transformation (especially stream processing), but all this is essentially repeating the book, which I recommend as an excellent read.
Contrary to the claim above, there is no additional layer of indirection simply from rotating one’s record-keeping perspective by ninety degrees. I have to reject outright the suggestion that joins are unnatural in a relational database. The opposite is true: there’s nothing more natural to a relational database than a join, and that’s even despite SQL barely paying lip service to Codd’s relational algebra. Heck, using a join instead of a predicate may even be faster, not least because decomposing entity data into recomposable per-component tables means less data to scan. And if it’s instead of an indexed query, well, an index is a relation too, so in terms of schema complexity that’s a wash. As for cognitive burden, how about the nails-down-a-blackboard dissonance of dealing with tables that grow ever further rightwards with each new product manager.
None of this is to downplay the sheer productive rapidity of letting your template generator spit out a bog-standard CRUD app, it’s more to undermine and challenge assumptions about what deserves to be the conventional default, and to suggest that we can safely and reasonably change perspective to allow a little programmer happiness in.
> Reduced column bloat, easy reusability, easy reporting and data extraction, ease of bulk transformation (especially stream processing)
Respectfully disagree. For one, reporting is easier when you don't have to JOIN more tables, not harder. Same for data extraction. And how can bulk transformation be harder just because a column is where it would intuitively reside and not in another table who knows where?
> I have to reject outright the suggestion that joins are unnatural in a relational database.
I'm afraid you misunderstood. It's unnatural to me, the developer, not to the database, to spread closely related columns across different tables.
And "tables that grow indefinetely" is doing a lot of heavy lifting for those arguments. Most tables don't grow indefinitely.
Like I said, smells like premature optimization. I optimize for humans first.
I think they're arguing that you get a performance gain. Personally the systems if deal with wouldn't gain from such and optimisation as there is too little data. So I'll stick to the simplest approach.
It doesn't come naturally because now you need a JOIN in your SQL just to fetch what was before a column. Or two queries instead of one.
Not to mention having closely related data spread in different tables increases cognitive load.
You just added a layer of indirection for what gain precisely?