Dynamic SQL vs Stored Procedure
Suggested Videos
Part 144 - exec vs sp_executesql in sql server
Part 145 - Dynamic sql table name variable
Part 146 - Quotename function in SQL Server
In this video we will discuss the advantages and disadvantages of Dynamic SQL and Stored Procedures based on the following aspects
1. Separating database logic from business logic
2. Network traffic
3. SQL Injection Attacks
4. Cached query plans reuse
5. Maintenance
6. Implementing flexible logic
Separating database logic from business logic : Stored procedures allow us to keep database logic separate from business logic. The benefit of keeping database logic separate from the business logic is that, if there is an issue with the business logic you know you only have to check the application code. On the other hand if the issue is with the database logic, you will only have to check and modify the stored procedure.
Another added benefit here is that, if you change the stored procedure there is no need to compile your application code and deploy it. Just modify the stored procedure and you are done. You will loose this benefit if you are composing your dynamic sql statements in client code, as you will have to change the application code if there is a bug. Changing the application code requires compilation, build and deployment.
Network traffic : Stored procedures reduce network traffic as only the procedure name and a few parameters need to be sent over the network. With dynamic SQL, you will have to send your entire sql statement over the network. If the query is a complex one, with 50 to 60 lines, imagine the increased network traffic between the client application and the database server.
SQL Injection Attacks : Stored procedures prevent SQL injection attacks. In general, dynamic SQL open doors for SQL injection attacks if not careful. However, even with dynamic SQL, we can prevent SQL injection attacks by using parameterised queries. In some cases where you need to pass a table name or a column name as a parameter, it is not possible to use parameterised queries with dynamic sql. In such cases use QUOTENAME() function to prevent SQL injection attacks.
Cached query plans reuse : Stored procedures provide increased performance as cached query plans reusability increases. Even with dynamic SQL, if we use parameterised queries, cached query plan reusability increases, which in turn increases the performance. If you are not using parameterised queries, SQL Server auto-parameterisation feature can automatically detect parameter values and create parameterised queries which promotes query plan reusability and in turn performance.
One important thing to keep in mind is that, from a performance standpoint OLTP queries benefit from cached query plan reuse. However, with OLAP systems as your data drifts and optimizer choices change, OLAP queries benefit from unique plans, so query plan reuse may not be desirable in this case for performance.
Maintenance : With static SQL in a stored procedure, a syntax error is reported immediately so ease of writing is definitely one of the benefits of using a stored procedure. On the other hand if you have dynamic SQL in the stored procedure, and if there is a syntax error you wouldn't know it until you run it.
Stored procedures with static SQL are also easy to maintain as you can use sp_depends procedure to check the dependencies on other SQL objects. For example, let's say you have a database with lot of tables, and you want to know if a certain table is referenced, because you are considering changing or dropping it. In this case using sp_depends TableName will let us know if it is referenced anywhere, so we can make changes without breaking anything. On the other hand if you are using dynamic sql in a stored procedure or sending it from a client, you loose this benefit.
Implementing flexible logic : Sometimes, with stored procedures it is hard to implement flexible logic compared with dynamic SQL. For example, we want to implement a "Search" stored procedure with 20 or more filters. This stored procedure can get complex. To make things worse what if we want to specify conditions like AND, OR etc between these search filters. The stored procedure can get extremely large, complicated and difficult to maintain. One way to reduce the complexity is by using dynamic SQL. Depending on for which search filters the user has provided the values on the "Search Page", we build the WHERE clause dynamically at runtime, which can reduce complexity.
Part 144 - exec vs sp_executesql in sql server
Part 145 - Dynamic sql table name variable
Part 146 - Quotename function in SQL Server
In this video we will discuss the advantages and disadvantages of Dynamic SQL and Stored Procedures based on the following aspects
1. Separating database logic from business logic
2. Network traffic
3. SQL Injection Attacks
4. Cached query plans reuse
5. Maintenance
6. Implementing flexible logic
Separating database logic from business logic : Stored procedures allow us to keep database logic separate from business logic. The benefit of keeping database logic separate from the business logic is that, if there is an issue with the business logic you know you only have to check the application code. On the other hand if the issue is with the database logic, you will only have to check and modify the stored procedure.
Another added benefit here is that, if you change the stored procedure there is no need to compile your application code and deploy it. Just modify the stored procedure and you are done. You will loose this benefit if you are composing your dynamic sql statements in client code, as you will have to change the application code if there is a bug. Changing the application code requires compilation, build and deployment.
Network traffic : Stored procedures reduce network traffic as only the procedure name and a few parameters need to be sent over the network. With dynamic SQL, you will have to send your entire sql statement over the network. If the query is a complex one, with 50 to 60 lines, imagine the increased network traffic between the client application and the database server.
SQL Injection Attacks : Stored procedures prevent SQL injection attacks. In general, dynamic SQL open doors for SQL injection attacks if not careful. However, even with dynamic SQL, we can prevent SQL injection attacks by using parameterised queries. In some cases where you need to pass a table name or a column name as a parameter, it is not possible to use parameterised queries with dynamic sql. In such cases use QUOTENAME() function to prevent SQL injection attacks.
Cached query plans reuse : Stored procedures provide increased performance as cached query plans reusability increases. Even with dynamic SQL, if we use parameterised queries, cached query plan reusability increases, which in turn increases the performance. If you are not using parameterised queries, SQL Server auto-parameterisation feature can automatically detect parameter values and create parameterised queries which promotes query plan reusability and in turn performance.
One important thing to keep in mind is that, from a performance standpoint OLTP queries benefit from cached query plan reuse. However, with OLAP systems as your data drifts and optimizer choices change, OLAP queries benefit from unique plans, so query plan reuse may not be desirable in this case for performance.
Maintenance : With static SQL in a stored procedure, a syntax error is reported immediately so ease of writing is definitely one of the benefits of using a stored procedure. On the other hand if you have dynamic SQL in the stored procedure, and if there is a syntax error you wouldn't know it until you run it.
Stored procedures with static SQL are also easy to maintain as you can use sp_depends procedure to check the dependencies on other SQL objects. For example, let's say you have a database with lot of tables, and you want to know if a certain table is referenced, because you are considering changing or dropping it. In this case using sp_depends TableName will let us know if it is referenced anywhere, so we can make changes without breaking anything. On the other hand if you are using dynamic sql in a stored procedure or sending it from a client, you loose this benefit.
Implementing flexible logic : Sometimes, with stored procedures it is hard to implement flexible logic compared with dynamic SQL. For example, we want to implement a "Search" stored procedure with 20 or more filters. This stored procedure can get complex. To make things worse what if we want to specify conditions like AND, OR etc between these search filters. The stored procedure can get extremely large, complicated and difficult to maintain. One way to reduce the complexity is by using dynamic SQL. Depending on for which search filters the user has provided the values on the "Search Page", we build the WHERE clause dynamically at runtime, which can reduce complexity.
by :- kudvenkat
No comments:
Post a Comment