I wonder what is the reasoning behind this? To escape the ambiguity during joins?
>Designs to avoid
>EAV (Entity Attribute Value) tables—use a specialist product intended for handling such schema-less data instead.
What if you have to use the data in some complex join-heavy query? Make a copy of the data needed in the relational database and hope that the data doesn't get unsynchronised?
> I wonder what is the reasoning behind this? To escape the ambiguity during joins?
Most justifications center around the "USING" clause which can only be used on matching column names:
select user_id,
username,
comment
from users
inner join
comments using (user_id);
The argument against this is that the USING clause really mucks up the result set columns by unifying those that match the USING clause.
Basic example would be the mandatory capitalisation of keywords.
Or why collective nouns instead of plurals? Why file_system and not files? The latter would serve better to avoid the common "file_" prefix of the tables, never mind that "file system" is ambiguous.
As for EAV, the first question isn't "what other product should I use for this" but whether stuff is really schema-less in the first place. For some kind of reason, people are really scared of defining new tables and views or extending existing ones… (Only place where I personally ever had problems with that was with a very enterprisey structure and strict DBAs. ITIL requests for every DDL)
The author kind of explained their justification in their blog post[1]:
>It beggars belief how many readers claim to have read the guide and yet I still get messages asking for justifications. At the very top, the introductory paragraph clearly states that Celko’s book is the place to find in-depth discussion of each point. Discussions of justification have no place in a style guide anyway.
Not sure I agree with this last point.
[1] https://www.simonholywell.com/post/2016/12/sql-style-guide-m...
> What if you have to use the data in some complex join-heavy query? Make a copy of the data needed in the relational database and hope that the data doesn't get unsynchronised?
No, he's saying that schema-less, arbitrarily-extended information has no business in a relational system at all.