articles >> developer >> SQL Server TSQL Coding Conventions, Best Practices, ...

SQL Server TSQL Coding Conventions, Best Practices, and Programming Guidelines

By : Vyas Kondreddi May 10, 2001

Printer friendly

Databases are the heart and soul of many enterprise applications, and it is very essential to pay special attention to database programming. I've seen in many occasions where database programming is overlooked, thinking that it's something easy that be done by anyone. This is wrong.

For a better performing database you need a real DBA and a specialist database programmer, let it be for Microsoft SQL Server, Oracle, Sybase, DB2 or whatever! If you don't use database specialists during your development cycle, databases often end up becoming the performance bottleneck. I decided to write this article in order to put together some of the database programming best practices so that my fellow DBAs and database developers can benefit!

Here are some programming guidelines and best practices, keeping quality, performance and maintainability in mind. This list many not be complete at this moment, and will be constantly updated. BTW, special thanks to Tibor Karaszi (SQL Server MVP) and Linda (lindawie) for taking time to read this article and providing suggestions.

• Decide upon a database naming convention, standardize it across your organization, and be consistent in following it. It helps make your code more readable and understandable. Click here to see the database object naming convention that I follow.
  
  
• Make sure you normalize your data at least to the 3rd normal form. At the same time, do not compromise on query performance. A little bit of denormalization helps queries perform faster.
  
  
• Write comments in your stored procedures, triggers and SQL batches generously, whenever something is not very obvious. This helps other programmers understand your code clearly. Don't worry about the length of the comments, as it won't impact the performance, unlike interpreted languages like ASP 2.0.
  
  
• Do not use SELECT * in your queries. Always write the required column names after the SELECT statement, like:

SELECT CustomerID, CustomerFirstName, City

This technique results in reduced disk I/O and better performance.

• Try to avoid server side cursors as much as possible. Always stick to a 'set-based approach' instead of a 'procedural approach' for accessing and manipulating data. Cursors can often be avoided by using SELECT statements instead.

If a cursor is unavoidable, use a WHILE loop instead. I have personally tested and concluded that a WHILE loop is always faster than a cursor. But for a WHILE loop to replace a cursor you need a column (primary key or unique key) to identify each row uniquely. I personally believe every table must have a primary or unique key. Click here to see some examples of using a WHILE loop.

• Avoid the creation of temporary tables while processing data as much as possible, as creating a temporary table means more disk I/O. Consider using advanced SQL, views, SQL Server 2000 table variable, or derived tables, instead of temporary tables.
  
  
• Try to avoid wildcard characters at the beginning of a word while searching using the LIKE keyword, as that results in an index scan, which defeats the purpose of an index. The following statement results in an index scan, while the second statement results in an index seek:
  
  SELECT LocationID FROM Locations WHERE Specialities LIKE '%pples'
  SELECT LocationID FROM Locations WHERE Specialities LIKE 'A%s'
  
  Also avoid searching using not equals operators (<> and NOT) as they result in table and index scans.
  
  
• Use 'Derived tables' wherever possible, as they perform better. Consider the following query to find the second highest salary from the Employees table:
  
  SELECT MIN(Salary) 
  FROM Employees 
  WHERE EmpID IN
  (
  SELECT TOP 2 EmpID 
  FROM Employees 
  ORDER BY Salary Desc
  )
  
  The same query can be re-written using a derived table, as shown below, and it performs twice as fast as the above query:
  
  SELECT MIN(Salary) 
  FROM 
  (
  SELECT TOP 2 Salary 
  FROM Employees 
  ORDER BY Salary DESC
  ) AS A
  
  This is just an example, and your results might differ in different scenarios depending on the database design, indexes, volume of data, etc. So, test all the possible ways a query could be written and go with the most efficient one.
  
  
• While designing your database, design it keeping "performance" in mind. You can't really tune performance later, when your database is in production, as it involves rebuilding tables andindexes, re-writing queries, etc. Use the graphical execution plan in Query Analyzer or SHOWPLAN_TEXT or SHOWPLAN_ALL commands to analyze your queries. Make sure your queries do an "Index seek" instead of an "Index scan" or a "Table scan." A table scan or an index scan is a very bad thing and should be avoided where possible. Choose the right indexes on the right columns.
  
  
• Prefix the table names with the owner's name, as this improves readability and avoids any unnecessary confusion. Microsoft SQL Server Books Online even states that qualifying table names with owner names helps in execution plan reuse, further boosting performance.
  
  
• Use SET NOCOUNT ON at the beginning of your SQL batches, stored procedures and triggers in production environments, as this suppresses messages like '(1 row(s) affected)' after executing INSERT, UPDATE, DELETE and SELECT statements. This improves the performance of stored procedures by reducing network traffic.
  
  
• Use the more readable ANSI-Standard Join clauses instead of the old style joins. With ANSI joins, the WHERE clause is used only for filtering data. Where as with older style joins, the WHERE clause handles both the join condition and filtering data. The first of the following two queries shows the old style join, while the second one shows the new ANSI join syntax:
  
  SELECT a.au_id, t.title 
  FROM titles t, authors a, titleauthor ta
  WHERE 
  a.au_id = ta.au_id AND
  ta.title_id = t.title_id AND 
  t.title LIKE '%Computer%'
  
  SELECT a.au_id, t.title
  FROM authors a 
  INNER JOIN
  titleauthor ta 
  ON 
  a.au_id = ta.au_id
  INNER JOIN
  titles t
  ON
  ta.title_id = t.title_id
  WHERE t.title LIKE '%Computer%'
  
  
  
      Next Page>>