I too have to deal with poorly structured queries from the others in my company. After having to deal with this for several years I have come to realize that the problem lies within the way many, mostly developers, typically view the SQL language. I believe most see SQL as something you sit down with a book and learn in 30 minutes. That's it. So long as you can write queries to do what you want then the query is a success. They seem to have no appreciation of the art of the query. I find this interesting as a developer is often very peculiar about there own VB or C code yet they do not apply that to working with SQL.
Unfortunately every one of the posts that contains an SQL statement has not retained its original structure and so everything runs together and therefore the reader can not appreciate what the poster was trying to convey. I personally believe that the proper structure of a query is:
Capitalize table names, table aliases and reserved word such as SELECT, FROM & WHERE.
Each clause (SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, etc) should start on a new line
Fields within the SELECT clause should use camel notation where the first character in each word is capitalized and all other characters are lower case
All fields should be aliased.
All joins should be done within the FROM clause unless there is some result set that can not be produced using that logic
Indentation should be used but not over used. Using 8 spaces for indentation is overkill and just makes it very difficult to read the query when it contains more then a few levels of indentation. After all who out there really needs to see 8 spaces to understand that you are use indentation?
Lastly, queries should be written neatly and with good form. I personally believe that developers write sloppy queries because they do not respect SQL and do not feel it deserves any of their time. Because of this they as do others who rush query construction take short cuts to save time. Shortcuts are the seeds of failure.
Robert, I am speculating here but I bet that you find it easier to use a,b & c for table aliases because you have been in the industry for a long time. It was not that long ago that memory was very precious and so every space in your code was expensive. This lead developers to write code in as brief a manner as possible so as to conserve on memory. Because of this it would have made sense to use single character table aliases in the convention of A,B,C, etc so as to minimize the space needed to reference the table. I bet that since you were probably first exposed to SQL in this type of environment that it is what you are most comfortable with and that is why you favor it over what the articles author has described as the best practice for table aliases. It has been my experience from dealing with persons of varying ages in the software industry that people tend to feel most comfortable with what they learned first. So developers who learned VB several years to '.Net' are hesitant to embrace VB.Net because it is a big step from VB6 or if they do embrace it they find it hard to switch to the VB.Net mentality. This is of course purely speculation.
Kindest Regards,Just say No to Facebook!