[deleted]
SQL style guide by Simon Holywell
11–20 of 76 posts
Re: SQL style guide by Simon Holywell
#12I’m probably alone in this, but I dislike naming tables in plural. IMO, reading “SELECT employee.first_name” makes much more sense than “SELECT staff.first_name”.
You are not alone at all, I also prefer singular names for the same reason. I reserve plural names for the rare cases where the single row of a table actually contains information about more than one item, which is usually when I'm doing something denormalized or non-relational e.g. CREATE TABLE user_settings ( user_id INT, settings_data JSON)
Re: SQL style guide by Simon Holywell
#13For comparison, here’s Mozilla’s SQL style guide: https://docs.telemetry.mozilla.org/concepts/sql_style
Re: SQL style guide by Simon Holywell
#14This is really good advice and the coding style (alignment) matches what I came to without any real guidance when I was learning SQL 20+ years ago. The only thing I slack on, is uppercasing the keywords. I hate switching case so much. But, I will fit the coding style of the codebase I am working on when it comes to that.
Re: SQL style guide by Simon Holywell
#15For comparison, here’s Mozilla’s SQL style guide: https://docs.telemetry.mozilla.org/concepts/sql_style
I am definitely not a fan of that style. Wastes too much vertical space without much benefit.
Re: SQL style guide by Simon Holywell
#16I’m probably alone in this, but I dislike naming tables in plural. IMO, reading “SELECT employee.first_name” makes much more sense than “SELECT staff.first_name”.
You can always alias to a singular … like
join users as user on user….
Then do as you please without the that if you are dealing with a user or leave it plural if multiple…
And if we’re talking personal preference I really dislike caps in reserved words in sql, even before highlighting was everywhere it still just feels archaic for no good reason
Re: SQL style guide by Simon Holywell
#17I’m probably alone in this, but I dislike naming tables in plural. IMO, reading “SELECT employee.first_name” makes much more sense than “SELECT staff.first_name”.
According to the guide it would be e.first_name or s.first_name.
Re: SQL style guide by Simon Holywell
#18I‘m not a fan of upper case keywords especially when there is also syntax highlighting that gives them a unique color.
Shifts my focus away from the rest of the query.
Re: SQL style guide by Simon Holywell
#19I‘m not a fan of upper case keywords especially when there is also syntax highlighting that gives them a unique color. Shifts my focus away from the rest of the query.
SQL keywords have been upper case for decades. I prefer it because it is faster to match visually.
Just like I don’t like uppercase paragraphs because of the same reason
Re: SQL style guide by Simon Holywell
#20Not bad advice. The one about “where possible avoid simply using id as the primary identifier for the table” stood out to me. In the past with multiple ORMs (ya, ya, we all hate them) the default was to map to a column named id. Also when doing joins its cleaner to use the table_name.id or alias.id then table_name.table_name_id or alias.table_name_id or whatever else besides id is used. The best is when multiple peop…
> Also when doing joins its cleaner to use the table_name.id or alias.id then table_name.table_name_id or alias.table_name_id or whatever else besides id is used
However, using 'table_name.table_name_id' and then having another table with an FK that references it with the same name i.e. 'table_2.table_name_id' allows you to use a shorthand 'USING' clause instead of 'ON' in databases that support it.