Yukon isn't out yet and won't be until next year. Don't base your needs today on something that's at least a year out.

Many times, business rules/logic require procedural processing of data. SQL Server sucks at this, but works well on set-based processing.

Business rules are not data rules. Things like referential integrity are data rules and belong 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.


>Umm yes.
>
>Would you care to read Bonnie's reply and then briefly justify why you are moving logic away from the location of the data? I'm not saying you are wrong, far from it, however I have two opposite opinions so I need to know a bit more.
>
>I can see why all data access should go through a common layer in order to provide consistent results. However what I'm really asking is: should the business object be in .Net or in SQL Server? With the availability of CLR support in Yukon this question will be asked a few more times no doubt.
>
>Regards
>Simon