Jan 10 2008 8:00AM GMT
Posted by: mrdenny
CLR,
Config,
SQL
There are two camps when it comes to SQL CLR. The DBA camp, which says don’t use it, it’ll kill your SQL Server and the Developer camp which says that it will save you loads of time and that you should use it for everything. These two different camps also represent the different messages which Microsoft is giving out as well. I highly recommend that DBAs sit in on a Microsoft developer track session and that developers sit in on a DBA track session some time. You’ll see a wide difference in the message about CLR in the sessions.
SQL CLR while powerful can not save the world as we know it from T/SQL. SQL CLR has it’s uses, and it has times when it is the wrong option. It can most definitely not do everything. First of all, you’ll notice that I call it SQL CLR not just CLR. This is because only a subset of the .NET CLR is supported by SQL Server. This subset it called the SQL CLR. The official list of supported libraries can be found here. If it isn’t on that list it’s not officially supported by Microsoft. What do I mean by supported? Well in basic terms if you are using a .NET CLR library which isn’t on that list and you start having performance issues, Microsoft can require that you remove the CLR code from the SQL Server before troubleshooting the issue. The official support policy from Microsoft can be found in MSKB article 922672.
Now with all that said what exactly can SQL CLR functions and procedures be used for?
SQL CLR code is extremely powerful, and when it comes to some kinds of work can be much faster than T/SQL code. Some examples are advanced math, string manipulation, string searching, pattern matching, etc. Places where SQL CLR will be slower than native T/SQL will be when general data manipulation and data searching. When writing SQL CLR functions and procedures do remember that if the .NET code has to go back to the database for any reason that data access will not be slower than doing the data access natively within T/SQL. If nothing else you have to account for the additional time to connect to the SQL Server, check credentials and move into the correct database. All of which takes time. When updating records from .NET code you have to process the records one at a time. While .NET is great at processing records row by row, SQL isn’t. SQL will be very slow when it comes to actually processing the updates as it is optimized for record set processing not row by row processing.
Now that I know what I can do with it, when should I?
When deciding to write a .NET SQL CLR function or procedure you first need to decide; Is the SQL Server the right place to do this? Often times the front end, or middle end (if you have an N tier application) may be a better place to do the work. For example formatting phone numbers via a .NET function should be done on the front end, not in the database. Encrypting a credit card number should be done in the middleware or the SQL Server (if you have a middleware layer do it there). You probably don’t want to install the encryption method and certificate that you use to encrypt data on the end users computer. The general rule that I like to live by is to put as much .NET code outside of the SQL Server as possible, either in the middleware or in the front end. Now there are also times when putting the code within the SQL Server is the right place to put it. Say that you are doing a data warehouse load and you need to parse the text of a NVARCHAR(MAX) field looking for specific key words or phrases, and if these key words or phrases exist you need to add rows somewhere else. T/SQL may not be the best option for this. A Full Text search will be inefficient as you will have to search the entire table every time. A regular T/SQL LIKE command will be very slow as indexes can’t be used, and searching through large pieces of text takes SQL a lot of time. But if you use a SQL CLR function this can be done with very little CPU time using what are called Regular Expressions. Regular Expressions are a basic .NET function which allows you to quickly and easily search a block of text. (Since I’m not a .NET programmer I’m not going to dive into using regular expressions, however here is an MSDN article on the topic.)
Other excellent uses of SQL CLR would include procedures or functions which involve advanced mathematics functions which SQL Server does not include. These functions could be easily put into a SQL CLR procedure or function and executed within the .NET environment with the result then being used within the SQL Server. While normally I would recommend putting this in the client tier or middle tier if the function or procedure was needed for in row processing of a query then the SQL Server may be the right place for the CLR code.
While the SQL CLR isn’t the end all solution that some people were looking for, and want it so desperately to be, when used correctly it can be an extremely powerful tool. But it must be used carefully as when used incorrectly it can hamper performance of your SQL Server.
Denny
4 Comments
RSS Feed
Email a friend
