No Need to Rush the CLR

It's been close to a year since I last wrote a doom-and-gloom editorial about the pending release of SQL Server 2005's Common Language Runtime (CLR), commonly called the SQLCLR. I decided to get back up on my soapbox one last time before the release to manufacturing (RTM) of SQL Server 2005 later this fall.

Let me start by saying that I think the SQLCLR is a wonderful addition to SQL Server and is unquestionably one of SQL Server 2005's most significant features. The CLR provides a way to craft elegant solutions to application and database problems that you can't easily handle on the Web layer or through T-SQL.

Even so, you shouldn't always do a thing just because you can. My primary concerns about the CLR involve performance tuning, which is where I spend most of my billable time these days. Today, most corporate IT shops (and most consulting companies) have relatively few people who are skilled in the art of diagnosing and solving database performance problems. That's not good or bad; it's just fact that I've encountered while working with a few dozen customers around the country. Many developers still don't even really grasp the fundamental fact that set-based operations are generally orders of magnitude more efficient than row-by-row operations.

Today, writing database-server code requires at least a rudimentary knowledge of T-SQL and some understanding of database principles in general. A knowledge mismatch between the .NET world and the database world often prevents .NET experts with zero database skills from writing lots of server code. But the SQLCLR removes that impediment. .NET developers will be able to write incredibly elegant solutions--as well as utterly hideous solutions. Arguably that's not much of a change from today's situation. But currently, at least one person wearing the DBA hat in an organization understands T-SQL and performance tuning and can help fix the worst of the inefficient procedures. Alas, for the first few months after SQL Server 2005 ships, and probably much longer, DBAs simply won't be up to speed on .NET code deployed in the SQLCLR and will have limited ability to troubleshoot it.

Microsoft has wisely turned off the CLR in SQL Server 2005 in accordance with its comprehensive "off by default" policy, which is designed to present a small attack surface to potential intruders. So here's my advice: Get excited about the SQLCLR. Use it wisely to create really cool solutions. Take advantage of its capabilities, especially if you're in a shop blessed with SQL Server performance experts who are skilled with .NET. But don't rush to use the SQLCLR just because you can. Much of the server-side code you'll write for SQL Server 2005 will still be T-SQL, and that won't change in the immediate future. And if you're a DBA, don't be afraid to push back at development teams clamoring to enable the SQLCLR if you don't feel comfortable supporting it right away.