Hey, Craig,

"However, for new development, business rules have no place in the database.

"Things like how to calculate the grand total of an invoice are not a data rule and should be in the business logic, outside of the database.

While that's a good base on which to start, I think the requirements of the application can also factor into these types of decisions.

One example is an aggregate calculation as part of a query. A remote user might be running a highly summarized report where a column(s) is calculated as part of a join (e.g. specific cost rates for a market * volume shipped by location), a weighted average, etc.

In those instances, the best performance is for the calculation to be part of the stored proc or in a back-end UDF...much faster than bringing down larger amounts of data to the business/application tier and have that do the number crunching.

Those types of rules/calculations are sometimes only needed for that situation. But I look forward to the promise of Yukon/Whidbey and what that could mean for better re-use and integration of CLR/database code.

Kevin