Almost certainly going to get flamed on this one - probably in the same league as 'Emacs or vi?'...
In this podcast, the team that are behind StackOverflow basically say that they think that the days of stored procedures are coming to an end. Now, obviously they're coming at it from a developer perspective, and I'm wondering if there are counter-arguments from a DBA perspective.
It breaks down this way, you can build a well-designed front-end application that uses well built parameterized queries and get just about every bit of performance and plan reuse that you can get out of stored procedures. There are two issues that will probably keep stored procedures alive into the future. The first is security. You can do a lot more granular manipulation of security through stored procedures than you can through parameterized queries. That's not needed for lots of applications, but it is for others. The other issue is deployment. I know that some developers and some shops have been able to get deployment down to a fine art so that they can make lots of small code changes and get them into production quickly and easily, so if query tuning is needed in these shops, changes to the code that generates the queries can be quickly rolled out into production. But lots of shops are not able to do this. So having an added layer, through stored procedures, allows for quick deployment and modifications that don't require complete code builds and all the associated testing required.
All this assumes that you're not talking about straight ad hoc SQL. That's still a frightening abomination, performance bottleneck, security hole, and all around problem. I know that lots of developers are in the "deliver the code and leave" mode of consultants. But for those that work full time and have to maintain applications over an extended period of time (I'm working on apps that are over 10 years old and there are 20+ year old apps in the company I work for) making poor design choices, such as ad hoc SQL, have enormous long term repercussions and ultimately have to be replaced with better applications.
answered Oct 15 '09 at 09:17 AM
Grant Fritchey ♦♦
I will always fall on the side of using stored procedures, because they are a much much cleaner interface to the database than queries dotted through source code. For example, if I know that stproc_ValidateUserLogin takes a login name and a password hash, and gives me back a user level - then do I really need to know whether that procedure accesses tblCfgUsers or tblCfgUsersNew underneath?
The other main key for me is in terms of producing reports. The way that I engineer things is to get as much of the job done as close to the source as possible. If I can return 15 rows of report to a client app, instead of 100,000 rows of source data, then that is a good thing. I am also more than willing to admit that SQL Server will do a better job of handling and aggregating that data than I would ever do in my own code...
The optimisation argument is probably tired now, seeing as the query optimiser now does a much better job of making plan re-use apply to ad-hoc queries as well as stored procedures.
answered Oct 15 '09 at 08:57 AM
Matt Whitfield ♦♦
I tend to agree with Grant's analysis (And voted it up). Timothy has a good comment as well.
I think the performance benefits are small at this point. The optimizer is very good, and even the ORM code is getting better. So is there a reason to use them?
For most people I would say yes. Timothy's premise of centralization, or code reuse, is a big one. You can get some of this be encapsulating the calls in a single method in an OOP client, but is that any better? Why not just write the procedure? I think you are splitting hairs here, and in that case, stored procedures are tuneable, and if you had to go cross platform, you could write the efficient procedure needed on each platform, without changing the client.
Security is the big one for me. Better control, and if you avoid dynamic SQL, you can avoid lots of SQL Injection.
Stack Overflow, and specifically Jeff Atwood and Joel's programmers are very, very disciplined, and very smart. I think what works for them doesn't necessarily work for others.
answered Oct 22 '09 at 08:21 PM
Steve Jones - Editor ♦♦
Just as a general comment, this type of question might be better at the main SSC site then here. I doubt there is any clear answer to this question.
With that out of the way, I do see ORM's such as Microsoft's Linq and SQLAlchemy for Python reducing the prominence of stored procedures, especially as they get better at what they do.
With that said, I think stored procedures have advantages that will keep them around for the forseeable future.
answered Oct 16 '09 at 03:56 PM
I find another reason to use stored proc's is dependency. If you have to make a change to a table or view, is sure is nice to know what objects depend on the table or view. With sql in the application, it is much more difficult to know what you have to test when making that kind of change.
I am pushing to put a policy in place to make all datasources for reporting service be stored procedure based because of this problem.
answered Oct 23 '09 at 05:14 PM