Static SQL vs Dynamic SQL
Monday, January 14th, 2008I have been wanting to write a few technical articles here on the blog, so I’ll start with something that is related with what I have been looking into at work: Static and Dynamic SQL.
From the conversations I have had with both DBAs and developers, it is clear that DBAs prefer static SQL, while developers prefer Dynamic SQL.
The difference between static and dynamic SQL is that static SQL needs to be compiled and bound to the database before application runtime, while dynamic SQL is compiled during runtime. Next, I’ll show a list of pros and cons regarding each one.
Static SQL
Pros:
- compile at bind time. Since the statement is compiled only once and before we run our workload, we have all the database resources in order to generate the most optimal query execution plan. In DB2, there are 9 levels of optimization, being 5 the default one. When we bing our application package, we can pick the highest optimization level – 9 – and get the most optimal execution plan. Using a higher optimization level requires more resources for the compile phase, but since our workload is not yet running, we can afford this high resources requirement.
- security. Security is probably the most common reason why people use static SQL instead of dynamic SQL. Static SQL allows the DBA to set authorization at the package level. For example, consider an application package app1, that provides SQL functionality to select employee’s name and address from the table employees. The DBA can five user JOHN execution privileges on package app1, even if user JOHN does not have SELECT authority on table employees. Static SQL provides a much finer layer of security.
Cons:
- need to bind before runtime. Although binding before runtime usually allows for more optimized access plans, doing this in a test or development environment can be cumbersome.
- lack of tooling support. most of current IDEs provide coding assistance with support for APIs like JDBC. The lack of support from development tools discourages the use of static SQL.
Dynamic SQL
Pros:
- IDEs and APIs: using eclipse to develop Java code that interacts with the database using JDBC or JPA is much simpler than developing a SQLJ application.
- statement caching. Dynamic statement caching avoids the need to compile the same statement multiple times, increasing the performance to values close to static SQL. However, bear in mind that a cache miss will be extremely expensive.
-
better statistics. Because the statement is compiled at runtime, it uses the latest statistics available, contributing to a better execution plan.
Cons:
- compile at runtime. There are a few reasons why compile at runtime can be a bad thing:
- every time a statement is executed, it needs to be compiled, increasing the total statement execution time
- the compile time will account for the total execution time, so using higher optimization levels may slow down the overall performance instead of improving it.
- because the statement is only compiled at runtime, errors in the SQL statement won’t be detected until runtime.
As you can see, there are several reasons why you would choose one over the other. There is no perfect solution! But if you ask me, I would suggest the following: use Static SQL if security is your main concern and use Dynamic SQL if ease of development is your main concern.
Popularity: 35% [?]
