I saw this insightful article on the subject in a “most popular articles” list. The author, Douglas Reilly, acknowledges at the beginning of the article that he uses stored procedures virtually all the time, but still does a great job of describing the pros and cons of each approach.
The most useful thing the article taught me was that as of version 7, SQL Server keeps execution plans for all statements, not just stored procedures. This reduces the advantage of stored procedures for basic CRUD (create, read, update, delete) operations substantially. I’ve certainly touted the superior performance argument in comparing stored procedures to ad-hoc SQL before, so I’m glad I learned the real deal now.
That said, I still hold a bias in favor of stored procedures. Once upon a time, I worked for Sybase Professional Services as a DBA, and they were definitely pro-stored procedure. Nearly every shop I’ve worked in since then has been similarly inclined. Anytime an employer has used ad-hoc SQL, it’s been absolute murder to maintain. In my experience, the maintenance advantage of stored procedures over ad-hoc SQL is substantial, not slight (as Reilly concludes).
One issue the article doesn’t bring up that might be interesting is source code control for stored procedures and other database elements (views, user-defined functions, etc). While SQL Server does have backup and restore, it’s not nearly as granular or convenient as the check-in/check-out model of today’s source code control systems. On my projects, I tend to generate a script with just the stored procedures in it and store that in SourceSafe. I’d certainly like a better solution, but haven’t found one yet. I’m curious to see what SQL Server 2005 is like, since it will allow you to write stored procedures in C# or VB.NET.
Comments