When should I use stored procedures?

Question

When should I be using stored procedures instead of just writing the logic directly in my application? I\'d like to reap the benefits of stored procedures, but I\'d also lik

Answer 1

The stored procedures are a method of collecting operations that should be done together on database side, while still keeping them on database side.

This includes:

• Populating several tables from one rowsource
• Checking several tables against different business rules
• Performing operations that cannot be efficiently performed using set-based approach

etc.

The main problem with stored procedures is that they are hard to maintain.

You, therefore, should make stored procedures as easy to maintain as all your other code.

I have an article on this in my blog:

• Schema junk

Answer 2

I used stored procs in 1 of 3 scenarios:

Speed When speed is of the utmost importance, stored procedures provide an excellent method

Complexity When I'm updating several tables and the code logic might change down the road, I can update the stored proc and avoid a recompile. Stored procedures are an excellent black box method for updating lots of data in a single stroke.

Transactions When I'm working an insert, delete or update that spans multiple tables. I wrap the whole thing in a transaction. If there is an error, it's very easy to roll back the transaction and throw an error to avoid data corruption.

The bottom 2 are very do-able in code. However, stored procedures provide an black-box method of working when complex and transaction level operations are important. Otherwise, stick with code level database operations.

Security used to be one of the reasons. However, with LINQ and other ORMs out there, code level DAL operations are much more secure than they've been in the past. Stored procs ARE secure but so are ORMs like LINQ.

Answer 3

I'd argue that you should avoid stored procedures.

Why might we avoid it?

• To avoid tight-coupling between applications and databases. If we use stored procedures, we won't be able to easily change our underlying database in the future because we'd have to either:

  1. Migrate stored procedures from one database (e.g. DB2) to another (e.g. SQL Server) which could be painstakingly time-consuming or...
  2. Migrate all the queries to the applications themselves (or potentially in a shared library)

• Because code-first is a thing. There a several ORMs which can enable us to target any database and even manage the table schemas without ever needing to touch the database. ORMs such as Entity Framework or Dapper allow developers to focus on building features instead of writing stored procedures and wiring them up in the application.

• It's yet another thing that developers need to learn in order to be productive. Instead, they can write the queries as part of the applications which makes the queries far simpler to understand, maintain, and modify by the developers who are building new features and/or fixing bugs.

I know of a company which was heavily reliant on stored procedures. As the number of microservices grew and as the original database-oriented developers left, the company was left with a black box that no one was allowed to touch for fear that it would take everything down. Now that they want to move to a different database and move to the cloud, it's much more difficult than it needs to be and they are moving the stored procedure logic into their applications anyways.

Answer 4

I tend to avoid stored procedures. The debugging tools tend to be more primitive. Error reporting can be harder (vs your server's log file) and, to me at least, it just seems to add another language for no real gain.

There are cases where it can be useful, particularly when processing large amounts of data on the server and of course for database triggers that you can't do in code.

Other than that though, I tend to do everything in code and treat the database as a big dump of data rather than something I run code on.

Consider Who Needs Stored Procedures, Anyways?:

For modern databases and real world usage scenarios, I believe a Stored Procedure architecture has serious downsides and little practical benefit. Stored Procedures should be considered database assembly language: for use in only the most performance critical situations.

and Why I do not use Stored Procedures:

The absolute worst thing you can do, and it's horrifyingly common in the Microsoft development world, is to split related functionality between sproc's and middle tier code. Grrrrrrrr. You just make the code brittle and you increase the intellectual overhead of understanding a system.

Answer 5

I tend to always use stored procedures. Personally, I find it makes everything easier to maintain. Then there is the security and performance considerations.

Just make sure you write clean, well laid out and well documented stored procedures.

Answer 6

Basically when you have to perform operations involving data that do not need to get out of the database. For example, you want to update one table with data from another, it makes little sense to get the data out and then back in if you can do it all in one single shot to the db.

Another situation where it may be acceptable to use stored procedures is when you are 100% sure you will never deploy your application to another database vendor. If you are an Oracle shop and you have lots of applications talking to the same database it may make sense to have stored procedures to make sure all of them talk to the db in a consistent manner.