Question

I read a book on SQLServer 2008. Within this book the author stated that although stored procedures are mostly the solution, you should avoid using them all the time.
I know that stored procedures are pre-compiled which as a result makes them run faster than normal commands. Also because they use parameters for passing data, they’re far safer than normal SQL commands in case of SQL injection attacks.
So what I don’t understand is: Why not always use stored procedures?

Answer 1

A good article on the subject

http://www.codinghorror.com/blog/2004/10/who-needs-stored-procedures-anyways.html

So I think you should do what you prefer. There is no performance difference (for msot of the query you’ll have to run).

I’d say go for no stored procedure : stored procedure are a pain in th a.. :

• no overloading : If you want to add a parameter you’ll have to update all your calls (or create a new SP)

• no complex type : with dynamic sql you can build all your sql filter like you want depending on your complex objects

• securiy is not a reason : if your sql query are sql injection proof and your database is not available for everybody, you can handle your data access security policy at the application level (any dba would kill me saying this, but any dev would agree… I guess)

SP are “pre-compiled” (at the first execution, the database server will find the best execution plan, for SQL server), BUT in our time we can forget about it, the “compilation” time is really little so we don’t have to worry about it. I never saw a case when I thought “OMG the compilation time is my application bottleneck”, most of the time your application bottleneck will be the query itself, so don’t worry about performance when you don’t have to.

And this “pre-compilation” depends on the parameters you send to the SP (on the first call), so sometimes you can have a lot of performance problem (called “parameter sniffing”) with SPs (see here :http://www.sqlpointers.com/2006/11/parameter-sniffing-stored-procedures.html).