No new comments.
View All Comments
No new messages.
View All Messages
No new notifications.
View All Notifications
Getting Started with Microsoft Bot Framework
CONGRATULATIONS: 2016 First Half MVPs Announced
Installing and Getting Started with .NET Core 1.0
Microsoft .NET Core is available now
Must Read: C# Interview Questions And Answers
A Code Snippet
An Interview Question
Ask a Question
Coding Best Practices
Universal Windows Platform
Databases & DBA
Design Patterns & Practices
Learn C# Corner
Robotics & Hardware
GDI+ & Graphics
How do I
C, C++, MFC
Internet & Web
Internet of Things
Request a new Category
Scroll To Top
Good Practices to Write Stored Procedures in SQL Server
Mar 01, 2012
This explains the good practices for writing stored procedures in SQL Server and the advantages of writing stored procedures.
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.
Advantages of the stored procedure
It will improve the execution. It will compile once and be stored as an object under the database. The same execution plan will be used for all the subsequent execution.
It will reduce the network traffic. It will have only a few bytes of parameters. But the inline query will make more traffic.
It will be stored in the SQL Server database and any number of applications which return in the multiple languages/application can utilizes the same stored procedure.
The permission can be set to the stored procedure.
The stored procedure can be changed the logics without redeploying the application in circumstances.
The application developers can work in the front end and the SQL developers they can write the SQL Server.
sql server articles
stored procedures in sql server
Object Oriented Programming Using C# .NET
Performance Optimization Techniques With Coding Standard Best Practices In C#
Using MVC 6 And AngularJS 2 With .NET Core
AngularJS CRUD Operations With Web API Using SQL Database
Useful Tools For AngularJS Developers
Consuming ASP.NET WebService In AngularJS
SQL Server Tricky Query Interview Question
DBA Skills For Developers
How To Get GeoLocation Address By Using Google GeoLocation API In ASP.NET Web API
CBeyond Cloud Services
TERMS & CONDITIONS
REPORT A BUG
©2016 C# Corner. All contents are copyright of their authors.
Terms & Conditions
©2016 C# Corner. All contents are copyright of their authors.