Good Practices to Write Stored Procedures in SQL Server
Reference to: http://www.c-sharpcorner.com/UploadFile/skumaar_mca/good-practices-to-write-the-stored-procedures-in-sql-server/
- Use proper indentation for the statements in SQL Server. It will improve the readability.
- Write the proper comments between the logics. So the others can understand quickly.
- Write all the SQL Server keywords in the CAPS letter. For example SELECT, FROM and CREATE.
- Write the stored procedure name with full qualified names.
CREATE PROCEDURE [dbo].EmployeeSalaryCalculation
- Always try to declare the DECLARATION and initialization at the beginning of the stored procedure.
- It is not recommended to use more variables in the procedure. It will occupy more space in the memory.
- Do not write the stored procedure name beginning with sp_. It is reserved for the system stored procedures in SQL Server and when the request comes to the SQL Server engine, it will be considerd to be a system stored procedure and looks for it in the master database. After it understands that this is a user defined stored procedure, it requires a bit more response time. So name the procedure name with another prefix such a proc_.
- Set the SET NOCOUNT ON option in the beginning of the stored procedure to avoid the unnecessary message like number of rows affected by the SQL Server.
- Try to avoid the temp table in the stored procedure. Stored procedures usually use a cached execution plan to increase the performance. When you use the temp table it will do the compilation every time.
- Do not use the select all columns (SELECT *) option; use only specific columns to query the result.
- Try to avoid the cursor in the stored procedure. It will consume more memories. It will degrade the performance of the stored procedure. Try to use the table variable and WHILE loop statement to iterate the query result set.
- Set the default value to the parameter and always set the size of the variable to be equivalent to or more than the table field column length. For example Name (10) in the table, but if you give Name(25) in the procedure then you will get the run time error time "string truncated error".
- Use the Try catch statement properly in the stored procedure to handle the errors in the runtime.
- Move the complex query into views.
- If you want to return the single column result then prefer to use the output statement to return the result to the calling program rather than table result.
- Avoid the sub-queries and use the INNER JOIN. Try to avoid the filtering condition in the where clause and it can be written in the joining time itself. When joins the table itself it will be filtered and it will filter again from the joined result table.
- Use the SELECT TOP 1 in the exists condition checking.
- Do not do like this:
SELECT @name=name FROM employees WHERE name like '%rob%'
This will give the run time error when returns more than one result.
SELECT TOP 1 @name=name FROM employees WHERE name like '%rob%'
It is always recommended to use the TOP 1 in that case. The result may differ from what is expected. - Avoid the nested IF statements and use the CASE statement. It will execute the matching part immediately.
- Dynamic Queries - Try to minimize the usage of dynamic queries. If you are using a dynamic query like:
SELECT * FROM mydb.dbo.emp where empid = @eid then there is no problem.
You can supply a value for the @eid parameter and there is no recompilation of the execution plan in the database cache. But if you are using a SQL query like SELECT * FROM emp where empid = " + @eid and supply a parameter.
- Use the ORDER BY and DISTINCT, TOP only when requires. The SQL Server engine will get the result first and it will do again the query execution for these operations.
- It is recommended to use a Table variable when the result set is small. It is always in the memory and when the limit exceeds it will be created as a table in the temp. But the temp table will be created on the temp database and that makes it slower.
- Use the proper indexing to the columns in the table. Do not create an index on the columns that are not used anywhere in the where clause. It will require an extra roundtrip to query the result.