Barry Gervin’s blog entry is picking up almost Hamlet’s question. The story topic is whether stored procedures or generated SQL is the one to use in application to access DB engine.
I guess as almost all cases in software this depends on circumstances as well. In our company we have long experience with both approaches and stored procedure is preferred winner although dynamic SQL is used extensively as well.
General rule we are following can be summed up to following:
1. Use stored procedure on DB which belongs and is fully controlled by our program
2. Use dynamic SQL in case we are accessing 3rd party storage
Why stored procedures?
The main reason why to select stored procedures for our DB is to think about them as about interface methods of data storage object. In this case can/must application programmer use just offered stored procedures (SP) and does not need to care about details in database implementation. DB programmer than apply whatever SQL “tricks” to make data stored efficiently and effectively. This DB tweaking is mostly useful when data are retrieved from DB using complex selection criteria “paging” and sorting with extensive use of temporary tables.
We have got large benefit from stored procedure even when have moved implementation from “standard” SQL access to hot-hot in-house failover solution. In this case additional support on DB layer was completely hidden from callers SP interface.
Management of production system is also one of the key factors influencing our decision what to use. We have find out with use of SP we are much better off when critical bug on data/DB layer is discovered in production environment and must be addressed within minutes/hours. I think this case is not quite usual requirement for “standard” application but in our case this approach saved our back several times already (i.e. because our trading system is dependent on third party is not really possible get definition and test all data combinations our application can receive from 3rd party system/exchanges. Problem is that once we get such “unusual” data we are usually forced to use/handle them as they are critical to client business. This is major reason we need to get almost instant intervention even on production system). With dynamically generated SQL, which is inherently part of the binary, this quick & dirty “hacking” isn’t simply possible to do in such short time.
Additionally with use of stored procedures we can get more system safety and stability when is done regular upgrades for different client with different version. In this case can multiple clients with different binary versions use same version of DB. Software with older version of binaries can safely run with updated DB as SP’s have default newly introduced parameters appended always at the end and set with some reasonable default value(s).
Last but not least point why we are using stored procedures is unit/integration testing. This point was not even mentioned in any of blog entries. With stored procedures we can do much more cleaner and fine grained unit testing and code review as specific details for each execution environment are cleanly separated.
When dynamic SQL is used?
On other side if we are not controlling database engine where we are storing/retrieving data we are using dynamic SQL. In this case we don’t need to do any modification external system which is always welcomed by our clients. Unfortunately we must know their DB schema in quite detail and relay on their capability to inform us when modification is done.
My Recommendations
If you have available DB developer(s) and you are expecting to develop mid or large size application which uses its own DB than preferred choice is use SP. I believe with this selection you will gain big advantage in long term.
If used DB is external to your application or application is really small in size than dynamic SQL can give you simpler code management. Unfortunately price you will pay is less clear source code as you are mixing SQL and programming language of your choice.