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

Answer 1

@Keith

Security? Why would sprocs be more secure?

As suggested by Komradekatz, you can disallow access to tables (for the username/password combo that connects to the DB) and allow SP access only. That way if someone gets the username and password to your database they can execute SP's but can't access the tables or any other part of the DB.

(Of course executing sprocs may give them all the data they need but that would depend on the sprocs that were available. Giving them access to the tables gives them access to everything.)

Answer 2

Advantages for Stored procedures:

More easily code reviewed.

Less coupled, therefore more easily tested.

More easily tuned.

Performance is generally better, from the point of view of network traffic - if you have a cursor, or similar, then there aren't multiple trips to the database

You can protect access to the data more easily, remove direct access to the tables, enforce security through the procs - this also allows you to find relatively quickly any code that updates a table.

If there are other services involved (such as Reporting services), you may find it easier to store all of your logic in a stored procedure, rather than in code, and having to duplicate it

Disadvantages:

Harder to manage for the developers: version control of the scripts: does everyone have their own database, is the version control system integrated with the database and IDE?

Answer 3

You list 2 pro-points for sprocs:

Performance - not really. In Sql 2000 or greater the query plan optimisations are pretty good, and cached. I'm sure that Oracle etc do similar things. I don't think there's a case for sprocs for performance any more.

Security? Why would sprocs be more secure? Unless you have a pretty unsecured database anyway all the access is going to be from your DBAs or via your application. Always parametrise all queries - never inline something from user input and you'll be fine.

That's best practice for performance anyway.

Linq is definitely the way I'd go on a new project right now. See this similar post.

Answer 4

Advantages for in Code:

• Easier to maintain - don't need to run a SQL script to update queries
• Easier to port to another DB - no procs to port

Actually, I think you have that backwards. IMHO, SQL in code is pain to maintain because:

• you end up repeating yourself in related code blocks
• SQL isn't supported as a language in many IDE's so you have just a series of un-error checked strings performing tasks for you
• changes in a data type, table name or constraint are far more prevalent than swapping out an entire databases for a new one
• your level of difficulty increases as your query grows in complexity
• and testing an inline query requires building the project

Think of Stored Procs as methods you call from the database object - they are much easier to reuse, there is only one place to edit and in the event that you do change DB providers, the changes happen in your Stored Procs and not in your code.

That said, the performance gains of stored procs is minimal as Stu said before me and you can't put a break point in a stored procedure (yet).

Answer 5

Think of it this way

You have 4 webservers and a bunch of windows apps which use the same SQL code Now you realized there is a small problem with the SQl code so do you rather...... change the proc in 1 place or push the code to all the webservers, reinstall all the desktop apps(clickonce might help) on all the windows boxes

I prefer stored procs

It is also easier to do performance testing against a proc, put it in query analyzer set statistics io/time on set showplan_text on and voila

no need to run profiler to see exactly what is being called

just my 2 cents

Answer 6

I'm firmly on the side of stored procs assuming you don't cheat and use dynamic SQL in the stored proc. First, using stored procs allows the dba to set permissions at the stored proc level and not the table level. This is critical not only to combating SQL injection attacts but towards preventing insiders from directly accessing the database and changing things. This is a way to help prevent fraud. No database that contains personal information (SSNs, Credit card numbers, etc) or that in anyway creates financial transactions should ever be accessed except through strored procedures. If you use any other method you are leaving your database wide open for individuals in the company to create fake financial transactions or steal data that can be used for identity theft.

Stored procs are also far easier to maintain and performance tune than SQL sent from the app. They also allow the dba a way to see what the impact of a database structural change will have on the way the data is accessed. I've never met a good dba who would allow dynamic access to the database.