Editorials

When Writing Stored Procedures – Smaller is Better

Webcast Today
The Balance of Powers, Understanding SharePoint Governance:

Is it an application? Is it a website? Is it a functional tool? No, look it up on the internet, it’s SharePoint! With most technologies users are provided with a "how to" manual and understand that complaints go to the IT department. Online collaboration powered by SharePoint doesn’t follow the same form of processes and procedures. We will explore how to create a governance plan that incorporates the needs of the organization (controls) and the user (ease of use).
Presented by: Adam Levithan

> Register Now
> Live date: 5/5/2010 at 12:00 Pacific (Today)

Featured Article(s)
Troubleshooting SQL Server 2008 Cursor Problems
In this article, Alexander Chigrik explains some problems that you can have when you work with SQL Server 2008 cursors. He also tells how you can resolve these problems.

When Writing Stored Procedures – Smaller is Better

By Ben Taylor


Well there’s a bold statement, so I suppose I have some explaining to do. Having written stored procedures for a couple of decades I have tried many different approaches. At first, my intention was simply to make them easy to read and maintain. My procedures tended to be longer and only modularized when I could share something with another stored procedure. It wasn’t easy to share temp tables prior to SQL 2000. And there was a lot of work, or copy and paste coding when duplicating parameters to pass back and forth. So, if there was no gain to modularize, I just didn’t do it.

I started learning to optimize my procedures and found that placing DDL statements at the beginning, and different query paths in different procedures increased the probability of re-used procedure plans from cache. My procedures became more modular at this point, even though re-use was not necessarily a result. With SQL 2000 it became even easier to share temporary tables, so part of the pain of breaking procedures apart was alleviated.

The last few years I have been unit testing my stored procedures using both inline scripts and NUnit. Using Test First Development (TFD) or even Test Driven Development (TDD) on stored procedures has resulted in much greater success. My stored procedures are much more resilient and easier to maintain. A side effect is that my stored procedures have become even more granular. They are easier to maintain and definitely easier to test. Now with SQL 2008, even passing temp tables and sets from one procedure to the next has become quite easy. So, the most determining factor I use when writing a procedure is “How do I test this?” The net result is more stored procedures that do much less, and are easy to test. There are a lot of side benefits as well…probably fodder for an article later.

What do you think? What has your experience been? Is there a best practice you have found you would like to share with SSWUG, or at least guidance developers should consider?

Drop me a note at btaylor@sswug.org

New SelectViews Show
Kalen Delaney on the show today talking about her work with SQL Server, upcoming workshops and other thoughts. Also on the show, SQL Server 2008 R2, Mary Leigh Mackey from AvePoint and much more.
[Watch the Show]