3 ms·

>Where possible avoid simply using "id" as the primary identifier for the table. I wonder what is the reasoning behind this? To escape the ambiguity during joi

>Where possible avoid simply using "id" as the primary identifier for the table. 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?

mhd 8y ago
Most styleguides really do benefit from rationales. Just stating something ex cathedra sounds rather patronizing. 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)
- ainar-g 8y ago
  >Most styleguides really do benefit from rationales. Just stating something ex cathedra sounds rather patronizing. 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-misconceptions/#where-is-the-justification https://www.simonholywell.com/post/2016/12/sql-style-guide-m...
Slackwise 8y ago
>> Where possible avoid simply using "id" as the primary identifier for the table. > 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); Versus `on user.id = comments.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.
amp108 8y ago
>> 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? No, he's saying that schema-less, arbitrarily-extended information has no business in a relational system at all.

mhd 8y ago

Most styleguides really do benefit from rationales. Just stating something ex cathedra sounds rather patronizing. 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)

ainar-g 8y ago
>Most styleguides really do benefit from rationales. Just stating something ex cathedra sounds rather patronizing. 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-misconceptions/#where-is-the-justification https://www.simonholywell.com/post/2016/12/sql-style-guide-m...

Slackwise 8y ago

>> Where possible avoid simply using "id" as the primary identifier for the table. > 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); Versus `on user.id = comments.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.

amp108 8y ago

>> 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? No, he's saying that schema-less, arbitrarily-extended information has no business in a relational system at all.