“Stored procedures shield you from change in the database.”

Scenario: Adding or deleting a column

Removing or adding a column to a table can affect the stored procedure signature. A straightforward example of this would be if there was a sproc that inserted comments. Now imagine that business wanted comments, but also the locality of where the person was commenting. You would now have to provide the latitude and longitude to the sproc. This could happen easily if you are re-factoring or adding/removing columns based on new requirements. When this type of change occurs it generally cascades through the application code, the test suite, the stored procedure, QA must test it, and lastly a deployment. It is clear that a stored procedure doesn’t always shield your application from change, in fact, it added an extra step since you not only had to alter the table, but you also had to be sure that you changed the stored procedure.

Scenario: Increasing or decreasing the size of a column

This time the stored procedure signature doesn’t change, but I’ll bet your application has some server side and/or client side validation to notify users about the appropriate limits of the said data type (most likely some varchar/text). Rinse and repeat the last set of steps before a new deployment since the stored procedure hasn’t saved you from change.

Indeed the scenarios mentioned can be failures of when there is a 1:1 mapping between your sproc and table(s), a result of rapid feature development, or just good old re-factoring. Some argue that in “real databases” this doesn’t happen. Bullshit. If this is true and this never happens in your shop, you must have the world’s most robust and flexible design known to man to account for any and all requests from the business. Congratulations, you and your team must piss excellence. I can’t remember a time where I have witnessed the holy grail of database design when this hasn’t occurred in some capacity. The fact is we must agree that this does happen some of the time.

There have been other comments supporting this statement by contending that when sprocs are used properly as a logical model abstraction over the physical one, it helps shield you from change in the database. Admittedly this approach can be a valid one, but sprocs, in my opinion and I’m sure others would agree, are more about the physical model than they are the logical one. I don’t know about you, but I rather perform logical data modeling at the class and/or object level where I can leverage both the behavioral aspects and the data aspects of my domain.

Conclusion
I think the bottom line here is that this shouldn’t be the single criteria for you to make something a stored procedure. My original conclusion on this statement was that it is a myth, but I may have been a bit overzealous to prove a clever article title. It is actually neither true or false, it actually depends on your situation.

“Code related to queries and transactions belongs in the database so make it a stored procedure.”

Let’s first consider this statement from a testability perspective. Is the code and logic inside your sprocs unit tested? Chances are they’re not. Can you confidently assert that your integration test suite covers the possibilities of someone introducing a bug or defect in the code of your sproc to the extent that your CI server will go red? Maybe. I guess what I am getting at is if more of your business logic resided in the application (where it belongs) then the probability and certainty of answering yes to both of these questions would be higher.

Now let’s consider this from a troubleshooting aspect. Let’s say someone mistakenly changes a stored procedure by accidentally messing up an if/else conditional. Your CI server may or may not go red with a broken build, but where are your developers going to look for the problem? By the time someone checks the broken test(s), looks at the application code, sifts through the commit log (Does your stored procedure code get versioned? It should.), the very last place a developer is looking to solve a problem is stored procedure code. If you’re not so lucky to have a broken build, it might pop up in the error log or through some regression testing.

How about the argument that if more than one application uses the database the logic should reside in a stored procedure? I disagree. The fewer applications using the same database the better. Especially since you could have one application provide REST or SOAP services to other applications. This circumvents duplication of code and it also abstracts the notion of the database to the other applications. In fact, some of your REST or SOAP services may use a sproc or two

Conclusion
I’m calling this a myth. Testability, troubleshooting, and multiple applications aside, I believe that modeling at the class and/or object level should be the preferred approach.

“Stored procedures are a type of SOA”

Stored procedures could be a type of SOA, however, I’m not sure that stored procedures meet all of the SOA definition criteria. Are sprocs loosely coupled? Are sprocs discoverable? Do sprocs enable reuse of logic? Are sprocs fully autonomous? I bet the answers to these questions would vary depending on who you ask. They are composable. They do optimize. They do conform to a service contract. They do encapsulate.

Conclusion
The jury for me is still out on this one. They seem like a crude type of SOA just touching on the outer edges of the definition. Gray areas are abundant.

“Stored procedures provide a good interface between the application and database.”

A good interface to the database provides developers ease and ability through good object design and abstraction where the underlying implementation details are transparent. A good interface decouples you. A decent interface and decoupling to the database would allow you to migrate from one database to the next with less pain. In my experience the more stored procedures and custom code that ends up your database translates in more work when attempting a migration. I’m sure there are plenty of shops that wish they could move away from their current database, but are afraid to because of the number of crusty stored procedures that have built up over the years.

Conclusion
Stored procedures are simply not a good interface.

“Stored procedures allow for finer more granular user permissions.”

If your DBA says it is easier for them to manage permissions on stored procedures instead of granting the appropriate permissions to the user(s) and table(s) for your application, does it make a stored procedure the right choice for a particular operation? If we are going to get into what is easier for whom, let’s discuss what makes things easier for developers (maybe some other time).
Now a couple readers have pointed out that from a security and auditing perspective stored procedures can be a better way to go. This is something I hadn’t considered before and thanks for bringing this up.

Conclusion
Stored procedures can provide finer more granular control and are more secure. But consider if this is a compelling reason to make what you’re working on a sproc? If you’re concerned about auditing – triggers are an excellent way to handle this. If you’re paranoid about the user doing something with table(s) that have sensitive data a stored procedure could a good way to go.

Stored procedures can shield you from an unruly schema or horrible design, but don’t always shield you from change in the database. All of that logic that could end up in a stored procedure try and keep it in your application if you can. Stored procedures are not an interface, nor are they an abstraction to the database. Stored procedures might be a crude SOA, but consider all the better options for an SOA implementation. If your DBA keeps barking about stored procedures in excess, consider the old adage “If the only tool you have is a hammer, you tend to see every problem as a nail”. I’m curious about other stories or hair brain reasons people may have wrongly promoted the use of stored procedures, if you’ve got a good one please comment.