SQL SERVER Database Coding Standards and Guidelines

Part 2
blog.sqlauthority.com/2007/06/05/sql-server-database-coding-standards-and-guidelines-part-2/

Pinal Dave

SQL Server Database Coding Standards and Guidelines Part 2

Coding Standards

Optimize queries using the tools provided by SQL Server 5

Do not use SELECT *
Return multiple result sets from one stored procedure to avoid trips from the application server to SQL server
Avoid unnecessary use of temporary tables

Use Derived tables or CTE (Common Table Expressions) wherever possible, as they perform better 6

Avoid using <> as a comparison operator

Use ID IN(1,3,4,5) instead of ID <> 2

Use SET NOCOUNT ON at the beginning of stored procedures 7

Do not use cursors or application loops to do inserts 8

Instead, use INSERT INTO

Fully qualify tables and column names in JOINs

Fully qualify all stored procedure and table references in stored procedures.
Do not define default values for parameters.

If a default is needed, the front end will supply the value.

Do not use the RECOMPILE option for stored procedures.

Place all DECLARE statements before any other code in the procedure.
Do not use column numbers in the ORDER BY clause.
Do not use GOTO.
Check the global variable @@ERROR immediately after executing a data manipulation statement (like
INSERT/UPDATE/DELETE), so that you can rollback the transaction if an error occurs

Or use TRY/CATCH

Do basic validations in the front-end itself during data entry

Off-load tasks, like string manipulations, concatenations, row numbering, case conversions, type conversions
etc., to the front-end applications if these operations are going to consume more CPU cycles on the database
server

1/5
 Always use a column list in your INSERT statements.

This helps avoid problems when the table structure changes (like adding or dropping a column).

Minimize the use of NULLs, as they often confuse front-end applications, unless the applications are coded
intelligently to eliminate NULLs or convert the NULLs into some other form.

Any expression that deals with NULL results in a NULL output.

The ISNULL and COALESCE functions are helpful in dealing with NULL values.

Do not use the identitycol or rowguidcol.

Avoid the use of cross joins, if possible.
When executing an UPDATE or DELETE statement, use the primary key in the WHERE condition, if possible.
This reduces error possibilities.

Avoid using TEXT or NTEXT datatypes for storing large textual data.9

Use the maximum allowed characters of VARCHAR instead

Avoid dynamic SQL statements as much as possible. 10

Access tables in the same order in your stored procedures and triggers consistently. 11

Do not call functions repeatedly within your stored procedures, triggers, functions and batches. 12
Default constraints must be defined at the column level.
Avoid wild-card characters at the beginning of a word while searching using the LIKE keyword, as these
results in an index scan, which defeats the purpose of an index.
Define all constraints, other than defaults, at the table level.

When a result set is not needed, use syntax that does not return a result set. 13
Avoid rules, database level defaults that must be bound or user-defined data types. While these are
legitimate database constructs, opt for constraints and column defaults to hold the database consistent for
development and conversion coding.
Constraints that apply to more than one column must be defined at the table level.

Use the CHAR data type for a column only when the column is non-nullable.14
Do not use white space in identifiers.
The RETURN statement is meant for returning the execution status only, but not data.

Reference:

2/5
5) 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 highly undesirable and should be avoided where possible.

6) Consider the following query to find the second highest offer price from the Items table:

1 SELECT MAX(Price)

2 FROM Products
3 WHERE ID IN
4 (
5 SELECT TOP 2 ID
6
FROM Products
7
ORDER BY Price DESC
8
)

The same query can be re-written using a derived table, as shown below, and it performs generally twice as fast as
the above query:

3/5
 1 SELECT MAX(Price)

2 FROM

3 (
4 SELECT TOP 2 Price
5 FROM Products
6
ORDER BY Price DESC
7
)

7) This suppresses messages like (1 row(s) affected) after executing INSERT, UPDATE, DELETE and SELECT
statements. Performance is improved due to the reduction of network traffic.

8) 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. For a WHILE loop to replace a cursor,
however, you need a column (primary key or unique key) to identify each row uniquely.

9) You cannot directly write or update text data using the INSERT or UPDATE statements. Instead, you have to use
special statements like READTEXT, WRITETEXT and UPDATETEXT. So, if you dont have to store more than 8KB
of text, use the CHAR(8000) or VARCHAR(8000) datatype instead.

10) Dynamic SQL tends to be slower than static SQL, as SQL Server must generate an execution plan at runtime. IF
and CASE statements come in handy to avoid dynamic SQL.

11) This helps to avoid deadlocks. Other things to keep in mind to avoid deadlocks are:

Keep transactions as short as possible.

Touch the minimum amount of data possible during a transaction.
Never wait for user input in the middle of a transaction.
Do not use higher level locking hints or restrictive isolation levels unless they are absolutely needed.

12) You might need the length of a string variable in many places of your procedure, but dont call the LEN function
whenever its needed. Instead, call the LEN function once and store the result in a variable for later use.

13)

1 IF EXISTS (

2 SELECT 1

3 FROM Products
4 WHERE ID =
50)

Instead Of:

4/5
 1 IF EXISTS (

2 SELECT COUNT(ID)

3 FROM Products
4 WHERE ID = 50)

14) CHAR(100), when NULL, will consume 100 bytes, resulting in space wastage. Preferably, use VARCHAR(100)
in this situation. Variable-length columns have very little processing overhead compared with fixed-length columns.

Complete Series of Database Coding Standards and Guidelines

SQL SERVER Database Coding Standards and Guidelines Introduction
SQL SERVER Database Coding Standards and Guidelines Part 1
SQL SERVER Database Coding Standards and Guidelines Part 2
SQL SERVER Database Coding Standards and Guidelines Complete List Download

Click here to get free chapters (PDF) in the mailbox

Reference: Pinal Dave (http://blog.SQLAuthority.com)

5/5