SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Two Best Practices!


Two Best Practices!

Author
Message
rhandloff
rhandloff
Valued Member
Valued Member (57 reputation)Valued Member (57 reputation)Valued Member (57 reputation)Valued Member (57 reputation)Valued Member (57 reputation)Valued Member (57 reputation)Valued Member (57 reputation)Valued Member (57 reputation)

Group: General Forum Members
Points: 57 Visits: 151
It is also worth pointing out that in SQL Server 2000, in addition to making your code more readble, you also get a noticable speed improvement by using ANSI joins.



Robert-161128
Robert-161128
Forum Newbie
Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)

Group: General Forum Members
Points: 1 Visits: 3

As a soon to be senior citizen, I would like to put in my 2 cents worth on the suggested naming convention for aliases. Being an over 40 developer with less than perfect eye sight, I find it much easier to distinguish between alias like a, b, or c than it is Mnemonic aliases like clo and clc. The similarities between aliases like clo and clc are some times distracting and easy to confuse. Plus it adds addition characters to the statements, which adds to the statement's length. I suppose the idea of readable code would depend on the eyes of the beholder.


Michael Lysons
Michael Lysons
SSCommitted
SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)

Group: General Forum Members
Points: 1511 Visits: 1422
Ironic that in this issue of SQLServerCentral we have an article about formatting (with very easy to read SQL examples) and this article with code that was unreadable at a glance, so I gave up on it.
John Scarborough
John Scarborough
Old Hand
Old Hand (344 reputation)Old Hand (344 reputation)Old Hand (344 reputation)Old Hand (344 reputation)Old Hand (344 reputation)Old Hand (344 reputation)Old Hand (344 reputation)Old Hand (344 reputation)

Group: General Forum Members
Points: 344 Visits: 52
Really enjoyed the article. I think however, we all know the best way to name table aliases and variables: After ex girlfriends and cartoon characters. ;-)

John Scarborough
MCDBA, MCSA
YSLGuru
YSLGuru
SSCommitted
SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)

Group: General Forum Members
Points: 1788 Visits: 1665
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.
Ed


Kindest Regards,

Just say No to Facebook!
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search