I just read a blog post by Adam Machanic and feel compelled to thank Adam on telling it like it is.
I 'd also like to regurgitate his comments and add a few of my own:
T-SQL is not going away.
T-SQL is still the only means of accessing data. Even integrated CLR code must use T-SQL to access data.
CLR integration is an extension to T-SQL and not a replacement.
CLR code can do some great things but it isn't meant to replace basic database abilities that are easily handled without it. For example, you will still write most, if not all of your stored procedures in T-SQL. Sure, you may make calls out to CLR-base objects in that stored procedure code (and you may not), but T-SQL will still reign king in your database. Instead, CLR code is meant for things such as custom data types, specialized constraint checking (RegEx validation always comes to mind), or specialized functions (parsing a delimited string into a table). These things are best or only doable via CLR code.
CLR code should not be used haphazardly.
You may even find that you don't need it in your particular database implementation - nothing wrong with that. But, when you do need to use it, it can really give you some additional power that T-SQL just isn't cut out for.
Business rules still belong in the business layer.
I can't stress this fact enough. Rules that apply to a particular business process and not to the data itself do not belong in the database. Rules that are always pertinent to the data, regardless of the business process using said data belong in the database. The former are business rules and the latter are data rules. Business rules belong in the business software and data rules belong with the data.
Finally, keep in mind that exceptions do occur.
And for any number of reasons, technical, political, or otherwise, you may have to put a data rule in the business layer or may be prevented from using CLR code in your database implementation.
--Peter