Sometimes you may not want a 'conglomerate' return. Lets say the conglomerate rule implements A, B and C. Yet, in some cases, only B is required. Then a seperate implementation of B [a copy] would have to be maintained just for those cases.

I did not know that data or its retrieval were considered a rule. Rather, I thought they [the data and retrieval] were part of the contract to implement the rule!

>I *almost* agree with you. I would recommend that you look at things on a rule-by-rule basis. If implementing a rule meant making more than a few trips back to the database for additional data, I'd give serious thought to implementing the rule in a stored procedure.
>
>-Mike
>
>
>>You should not be putting your business rules into SQL Server if you are designing an n-tier solution. That essentially makes it two-tier.
>>
>>
>>>Hi
>>>
>>>What is SQL-Server's procedural language like? Is it any good to use as a middle-tier?
>>>
>>>This will be for a complex system where the rules are pretty heavy.
>>>
>>>Thanks
>>>Kev