To be clear, I don't mean to imply that I have some awesome magical way of writing queries that makes the hairiest queries easy to understand for even the most junior of devs. But this is an example of how I write them:
That may not look "revolutionary", but there are a few key points to this format:
Every item in the return list is on its own separate line.
Every field is fully qualified. (Nothing is simply referenced as firstName or accessLevel. It's always referenced as person.firstName or permission.accessLevel.
In the case of a SELECT, the order is alwaysSELECT followed by FROM followed by any-and-all JOINs, followed by any-and-all filters, followed by ORDER BY (if needed).
Keywords are always capitalized.
In the case where the tables/columns are not clearly named, I always alias them into easier-to-read names, like this:
If this queries tends to "grow" over time, as the dev team decides that they need to add more return values and more JOINs to it, it becomes ever-more-difficult to simply read.
I see what you mean. Not magical but definitely better. I use SQL infrequently but I've written queries the second way and now I'm going to write them your way. It is much clearer 👍.
Thanks!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
To be clear, I don't mean to imply that I have some awesome magical way of writing queries that makes the hairiest queries easy to understand for even the most junior of devs. But this is an example of how I write them:
That may not look "revolutionary", but there are a few key points to this format:
firstName
oraccessLevel
. It's always referenced asperson.firstName
orpermission.accessLevel
.SELECT
, the order is alwaysSELECT
followed byFROM
followed by any-and-allJOIN
s, followed by any-and-all filters, followed byORDER BY
(if needed).Also, I never alias them into one-or-two-letter abbreviations. I hate this:
In contrast, I often see queries written something like this, and I hate it:
If this queries tends to "grow" over time, as the dev team decides that they need to add more return values and more
JOIN
s to it, it becomes ever-more-difficult to simply read.I see what you mean. Not magical but definitely better. I use SQL infrequently but I've written queries the second way and now I'm going to write them your way. It is much clearer 👍.
Thanks!