Friday, August 3, 2012

SQL Coding Standards: Your Argument is Invalid

It may just be me, but it seems like the Coding Standards debate will never end. A Google search for "sql server coding standards" comes up with "About 738,000" results. A search for "coding standards" at SQL Server Central nets 85,666 items (articles, forum posts, and maybe some other things). Everything has ideas on what they think the standards should be. Many of these notions are carried down from years or even decades of experience. I argue that all your experience may just be a crutch holding up the habits you have developed over the years and your argument is invalid.

There is a book out there that every database professional from business analyst to cave-coder needs to read. It's a book on SQL coding standards written by a guy with decade of experience working on the ANSI SQL standards committee and countless hours of coaching, teaching, and enlightening the relational database community. This man is Joe Celko and the book is Joe Celko's SQL Programming Style (The link goes to Amazon.com and I receive nothing if you buy the book unless you read it an come work with me at which point I benefit from the knowledge you have gained.)

Sure, Joe can be a surly old curmudgeon who appears to like nothing better than blasting developers and DBAs in forums and newsgroups. That doesn't mean he isn't a fount of really good information. What's more important, especially with relation to the SQL Programming Style book is that he backs up his assertions with even better information. All that experience he has doesn't mean squat. What is important is that Mr. Celko isn't one of those people who wraps himself in the armor of experience. He recognizes that he isn't the expert on everything and doesn't pretend to know everything about the topics he is an expert on.

This really comes out in the SQL Programming Style because Celko backs up each and every recommendation in the book with a reason why. What's more, the reason is never "because I've been doing it this way since before you knew how to spell 'SQL'."

Here is how the book breaks down:
Names and Data Elements - Describes in simple terms how the ISO-11179 metadata standards should be applied to database objects

Fonts, Punctuation, and Spacing - Applies studies and knowledge about how the human brain works to how SQL code should be formatted

Data Declaration Language - Based on the principle that good code should be at least partially self-documenting, this chapter has some really good information on how to lay out your DDL so others can look at it and understand what you're trying to accomplish.

Scales and Measurements - Discusses measurement theory and how it should apply to your schema design

Data Encoding Schemes - Another excellent design-consideration chapter; this one covers how to choose the right encoding scheme for your data as well as how to design new encoding schemes (when you absolutely have to).

Coding Choices - This is where Celko gets into coding style for your DML. This chapter covers code portability (which is the one thing I don't necessarily buy into 100%) and a little bit about stored procedures (not T-SQL specifically).

How to Use Views - To the end user, a view should look just like a table. This chapter explains why and how you should implement them.

How to Write Stored Procedures - More detail on implementing stored procedures in a general sort of way.

Heuristics - This is an awesome discussion on how to analyze the problem to find the best database solution.

Thinking in SQL - A nice set of examples to show you how set-based programming is different from procedural or object-oriented development.

Resources and Bibliography - The book wraps up with a nice set of resources you can use for further research as well as a list of references Celko used.

OK, go buy the book now. Better yet, buy two so you can loan one out to someone you work with that could also benefit.

Disagree with me? You won't be the first. Tell me what you think in the comments and let's debate the issue.

No comments:

Post a Comment