Still dont get why sql uses all caps for keywords. It's one of the few languages that has it as a best practice. I can read C/JavaScript/go just fine without all caps. I do it anyway to conform.
And yet you misspelled "SQL."
SQL style guide
101–110 of 151 posts
Re: SQL style guide
#102I have often seen commas placed at the start of each line when columns are being listed. I'm a little surprised this guide doesn't follow that convention. It would fit nicely with the established pattern of lining everything up: SELECT first_name , last_name , email_address FROM users Can anyone speculate why it's not done this way in the guide? I think the reasoning behind it was to make later modification easier be…
This is a pretty commonly asked question. The answer is two fold: 1. putting the comma before doesn't actually make commenting out columns easier - it just moves the problem to the other end of the list. Just try commenting out `first_name` in your example and you'll see what I mean. 2. because normal convention would be for the comma to come immediately after an item in written English.
Re; #1, I also use comma-first indenting and I actually put each field in it's own line specifically for ease in commenting (first_name would have its own line)
Re: SQL style guide
#103Earlier quoted context omitted.
This is a pretty commonly asked question. The answer is two fold: 1. putting the comma before doesn't actually make commenting out columns easier - it just moves the problem to the other end of the list. Just try commenting out `first_name` in your example and you'll see what I mean. 2. because normal convention would be for the comma to come immediately after an item in written English.
Re; #1, I also use comma-first indenting and I actually put each field in it's own line specifically for ease in commenting (first_name would have its own line)
This doesn't solve the problem at hand either unfortunately. You'll still have a hanging comma in front of `last_name`:
SELECT
-- first_name
, last_name
, email_address
FROM users
SELECT
, last_name
, email_address
FROM usersRe: SQL style guide
#104Weird, I really dislike a lot of the suggestions. In particular, an example: SELECT first_name AS fn FROM staff AS s1 JOIN students AS s2 ON s2.mentor_id = s1.staff_num; We already agreed that staff is a good name for a table, so why are we renaming it to s1? There are all sorts of subtle bugs that arise when s2.mentor_id = s1.staff_num is wrong, and the variable names provide no help here that we're doing things rig…
SELECT staff_first_name
FROM staff
JOIN students
USING(staffId)
I always put table_name_field. The most reason is for my auto generation code.
Re: SQL style guide
#105Re: SQL style guide
#106Earlier quoted context omitted.
Aliasing tables is very useful. Aside from giving shorter names and helping you to be explicit when selecting fields, they also end up being useful for working with IntelliSense (or the equivalent in the tool you're using). Plus, you can make them memorable enough (e.g. in the first example you shared, could use 'S' for staff and 'ST' for students) for the query you're working on and shortening the query code makes i…
> S for staff and ST for students This isn't memorable: staff and students both start with st!
I'm aware of that. However, it only has to be memorable for the period of time you're working with a query. If you open up an old view or stored procedure to modify it, you would read the table aliases first. If someone wasn't able to retain the meaning of 'S' and 'ST' for the length of time needed to modify a query then perhaps working with code isn't for them.
Lastly, if someone did have poor memory they could lengthen the aliases to STA and STU.
Re: SQL style guide
#107The part about indentation is a bad practice to follow.
Indenting the code that way is not maintainable. I witnessed that multiple times in my career and adopted three simple rules:
1. Use only one space character between any two words.
2. Use only one tab (4 spaces) per indentation level.
3. Use no more than two blank lines to vertically separate parts of the code.
Re: SQL style guide
#108Arrgghhh... yet another set of rules with no rationale or justification.
Have you read Celko's book? If not I suggest you do. As the guide states at the very top that is where you'll find the detail you're after.
Re: SQL style guide
#109Let's just agree that we will all disagree.
Then let's agree just to accept that there is no ideal, but that there is benefit in using the same formatting, and that perhaps we should create a sqlfmt utility like gofmt and all just use that.
Re: SQL style guide
#110Weird, I really dislike a lot of the suggestions. In particular, an example: SELECT first_name AS fn FROM staff AS s1 JOIN students AS s2 ON s2.mentor_id = s1.staff_num; We already agreed that staff is a good name for a table, so why are we renaming it to s1? There are all sorts of subtle bugs that arise when s2.mentor_id = s1.staff_num is wrong, and the variable names provide no help here that we're doing things rig…
its not renaming its an alias if you have a complex sql statement having aliases just makes it easy to get you head around the code.
>its not renaming its an alias
That's what the parent meant with renaming too -- not that there's an actual table RENAME on the database.
An alias is a rename in the sense that it gives a different name for the same referenced table during the query.