There are several reasons why it is advantageous to separate the rules and put them in different procedures. For the most part, the reasons are the same as why its good to use seperate functions/subroutines in other programming languages. First, you reduce the amount of code in a single stored procedure, thus making maintenance of the rules much simpler. This also enables multiple developers to work on the rules at one time. If a system's primary function involves processing 50 or 100 non-trivial business rules against some set of data, the development of the rules can be a very time-consuming task. If this task can be split up between 6 developers, the system can get done much more quickly. I realize that since the rules affect the state of the system, the actions of one rule can potentially affect actions of another. However, with proper planning, requirement specs, and design documentation for each of the rules, this work can still be effectively partitioned amongst several developers.
Another benefit of breaking each of the rules out into its own procedure is that it separates the control of flow logic from the actual processing logic. Thus, when developing the rules, you don't have to worry about when the rule should be called, only what it is supposed to do and whether or not it is making changes to the state of the system that would adversely affect other rules. Even the simplest control of flow mechanism should have at least two routes: a normal route and an error route. If all is well, continue processing; otherwise, call the error handling routine. Coding the control of flow logic is easier if you don't have to worry about actual rule processing in the middle of your control of flow code. This also simplifies testing of your control of flow system. As long as the control of flow system communicates with the rules themselves only by well-defined interfaces, the control of flow system should work correctly no matter what changes are made to the rules.
The separation of the control of flow logic also enables more complex systems to be implemented more easily. For instance, a state machine could be used to control the order of execution of the rules. Since a state diagram is essentially a directed graph with a few special features, it can be represented in a database quite easily. (SQL For Smarties by Joe Celko has a good chapter on representations of graphs in relational databases.)
I've seen quite a few newsgroup posts asking how to dynamically change databases so that different tables can be updated depending on some parameter value. This can be quite easily accomplished by using interface-based programming techniques. In this case, you could have the same stored procedure in different databases. You then create a lookup table that maps whatever parameter determines which data gets updated to the name of the fully-qualified name of the stored procedure used to update the data. The same technique works across linked servers.
In short, I think there are quite a few uses for this technique. Is it the end-all be-all of application design? Of course not. However, when needed, the techniques presented can provide an easy-to-implement design that is easily maintainable down the road.
Now a question for everyone else... Based upon this article and this post, do you think a future article that focuses on specific applications of this technique (such as I mentioned above) would be useful?
Interfaces are an in interesting topic to be sure. The advantage that "bigger" languages have is that they can enforce the interface - in VB using the implements statement. That keeps intellisense working and helps the compiler do the checking. SQL doesn't have implements, so you have to enforce it by convention.
From a client coding perspective it makes sense to do this especially if you're manually populating the parameters collection in ADO to avoide the extra round trip. You can change the proc name and everything else works.
I'd be interested to hear your response about why it wouldnt be just as effective to put all the rules in one proc and just branch to the appropariate code based on a passed parameter.