What are the pros and cons to keeping SQL in Stored Procs versus Code [closed]

Answer 1

The performance advantage for stored procedures is often negligable.

More advantages for stored procedures:

• Prevent reverse engineering (if created With Encryption, of course)
• Better centralization of database access
• Ability to change data model transparently (without having to deploy new clients); especially handy if multiple programs access the same data model

Answer 2

I'm not a big fan of stored procedures, but I use them in one condition:

When the query is pretty huge, it's better to store it in the database as a stored procedure instead of sending it from the code. That way, instead of sending huge ammounts of string characters from the application server to the database, only the "EXEC SPNAME" command will be sent.

This is overkill when the database server and the web server are not on the same network (For example, internet communication). And even if that's not the case, too much stress means a lot of wasted bandwith.

But man, they're so terrible to manage. I avoid them as much as I can.

Answer 3

Smaller logs

Another minor pro for stored procedures that has not been mentioned: when it comes to SQL traffic, sp-based data access generates much less traffic. This becomes important when you monitor traffic for analysis and profiling - the logs will be much smaller and readable.

Answer 4

I am a huge supporter of code over SPROC's. The number one reasons is keeping the code tightly coupled, then a close second is the ease of source control without a lot of custom utilities to pull it in.

In our DAL if we have very complex SQL statements, we generally include them as resource files and update them as needed (this could be a separate assembly as well, and swapped out per db, etc...).

This keeps our code and our sql calls stored in the same version control, without "forgetting" to run some external applications for updating.

Answer 5

I like stored procs, dont know how many times I was able to make a change to an application using a stored procedure which didn't produce any downtime to the application.

Big fan of Transact SQL, tuning large queries have proven to be very useful for me. Haven't wrote any inline SQL in about 6 years!

Answer 6

I prefer keeping in them in code (using an ORM, not inline or ad-hoc) so they're covered by source control without having to deal with saving out .sql files.

Also, stored procedures aren't inherently more secure. You can write a bad query with a sproc just as easily as inline. Parameterized inline queries can be just as secure as a sproc.