Advantage of SQL SERVER CLR

I'll give one good example: CLR has a built in RegEx object, which is sorely lacking in SQL Server. Now it's trivial to write functions to do regex-based validation constraints/repairs.

Different purposes. A CLR stored procedure is useful for things where writing highly procedural code or using system facilities not accessible from T-SQL would be of benefit. Although there is no inherent reason why one can't write application sprocs against it, generally you would not view CLR sprocs as a merely a different language for writing application sprocs. Typically, most uses of a CLR sproc would be for system purposes rather than application components, although this is by no means a hard and fast rule.

The CLR integration layer does offer some facilities that are not directly available from T-SQL stored procedures, such as custom aggregate functions. It also offers access to .Net libraries, which may be useful to get access to capabilities that T-SQL cannot support.

T-SQL does traditional database stuff, and integrates with the query optimiser, so it is still most appropriate for set-oriented database code. There are API hooks for CLR sprocs to provide information to the query optimiser, but this adds some complexity.

One can also use CLR integration to define functions that are accessible to T-SQL code. In some cases these can be faster and more memory efficient than T-SQL functions. The Wrox press book on CLR integration discusses this in some depth.

You can also e.g. call an external Webservice from a SQLCLR method - not exactly possible in T-SQL :-)

Marc

SQLCLR / CLR Integration within SQL Server is just another tool to help solve certain (not all) problems. There are a few things that it does better than what can be done in pure T-SQL, and there are some things that can only be done via SQLCLR. I wrote an article for SQL Server Central, Stairway to SQLCLR Level 1: What is SQLCLR? (free registration is required to read articles there), that addresses this question. The basics are (see the linked article for details):

• Streaming Table-Valued Functions (sTVF)
• Dynamic SQL (within Functions)
• Better Access to External Resources / Replace xp_cmdshell
  • Passing data in is easier
  • Getting multiple columns of a result set back is easier
  • No external dependencies (e.g. 7zip.exe)
  • Better security via Impersonation
• Ability to Multi-thread
• Error Handling (within Functions)
• Custom Aggregates
• Custom Types
• Modify State (within a Function and without OPENQUERY / OPENROWSET)
• Execute a Stored Procedure (read-only; within a Function and without OPENQUERY / OPENROWSET)
• Performance (note: this is not meaning in all cases, but definitely in some cases depending on the type and complexity of the operation)
• Can capture output (i.e. what is sent to the Messages tab in SSMS) (e.g. PRINT and RAISERROR with a severity = 0 to 10) -- I forgot to mention this one in the article ;-).

One other thing to consider is, sometimes it is beneficial to be able to share code between the app and the DB so that the DB has insight into certain business logic without having to build custom, internal-only screens just to access that app code. For example, I have worked on a system that imported data files from customers and use a custom hash of most of the fields and saved that value to the row in the DB. This allowed for easily skipping rows when importing their data again as the app would hash the values from the input file and compare to the hash value stored on the row. If they were the same then we knew instantly that none of the fields had changed so we went onto the next row, and it was a simple INT comparison. But that algorithm for doing the hash was only in the app code so whether for debugging a customer case or looking for ways to offload some processing to back-end services by flagging rows that had at least one field with changes (changes coming from our app as opposed to looking for changes within a newer import file), there was nothing I could do. That would have been a great opportunity to have a rather simple bit of business logic in the DB, even if not for normal processing; having what amounts to an encoded value in the DB with no ability to understand its meaning makes it much hard to solve problems.

If interested in seeing some of these capabilities in action without having to write any code, the Free version of SQL# (of which I am the author) has RegEx functions, custom Aggregates (UDAs), custom Types (UDTs), etc.