When are advantages using stored procedure over hard coded query?

Question

It is very common but important question for me as in my project I started converting hard coded query into stored procedure, and I know the advantage using of this. However, is there any specific scenario where I should avoid using Stored Procedure?

Answer 1

There is a standard blog post I send to everyone who thinks stored procedures always make sense except in very rare conditions. They generally cite a fallacy along the lines that you just need to make a law against killing people in order to stop murderers.

http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx

The link above lists a lot of really good arguments about when, and when not, to use stored procedures. Among them are that, especially in C#, you basically ignore everything the framework gives you, in terms of the power to have sensible UI decisions for queries, in favour of ... a maintenance nightmare.

Answer 2

It's generally always better to use stored procedures. When using them the main advantage is that if you run the query multiple times, with the stored procedure it will keep the execution plan for reuse.

There are plenty of advantages of using them, see here for reference: http://blog.sqlauthority.com/2007/04/13/sql-server-stored-procedures-advantages-and-best-advantage/

Edit: Whilst the article is from 2007, the key principles are largely the same

Answer 3

This question gets asked a lot and here is a good post on the subject.

However I personally would say avoid complex logic in stored procedures its hard to maintain later and is not the best place to put it. ORM mappers are used pretty extensively now and some of the bigger ones (Hibernate/NHIbernate, EF etc) all produce optomised queries and have excellent caching strategies.

Also avoid a system with many many many stored procs (I've seen a system with over 4k stored procs and trust me you don't want to go there).

Edit

I should have expanded on my answer and will do so now, stored procs do however have a great use because they are executed on the server itself they are great where large amounts of data need to be processed and not bought back over a network connection and you might need several round trips to the database to acheive the same result, then I tend to optomise in stored procedure, most ORMS can execute a sproc and bring back mapped results and so this adds to the richness of the orm solution.

However if you find all you are doing is executing sprocs exclusively via an ORM, then you don't really need the orm. So these days its a performance optomisation. Where large datasets are concerned. Also there tends to be a lot of misinformed opinion/habits from both devs and DBAs a like which can lead to a war-like state of affairs, where people are told "all code must be in sprocs" or "all code must be generated by orm", this is a silly state of affairs.

The other thing I would point out is I have seen sprocs with all sorts of bugs in them and by our nature software devs aren't usually the best people to be writing sql as we don't tend to think in a "set-like" manner. Thats not to say devs can't write great sql code its just not our specialism.

How many times have you see a sproc which goes down a code path once.. gets its plan cached and then is suboptimal as a result because every subsequent time it doesn't go down that path... I've seen that a lot.

Answer 4

The Best practice is to use Stored Procedures.

1. Separation of work.
2. Reusable (can test directly from SQL)
3. You can use one procedure for many purpose it will reduce your time if some changes happen in your software.
4. No need to replace any code in program specially in DLL.