在SQL Server 2005的许多被大力推荐的特性里面，有一项可能对那些使用SQLServer 任务的编程人员最实用的是Common Language Runtime，或者简写为CLR。CLR可以让编程人员直接在SQL Server中创建存储过程、触发器，用户自定义函数，集合体和类型。CLR有很多的承诺，但是也有一些缺陷。

　　关于CLR的重要性有一些次要的缘由。首先，随着SQL Server 编程技术的成熟，代码编写人员堕入了SQL Server本身的一些限制之中，并且在很大程度上依赖外部的代码来执行一些繁重的移植。T-SQL (事务处理SQL)在前往数据集方面很好，但是除了这个之外则表现不佳。CLR使得问题的处理有了可能，并且在SQL Server内部进行数据操作，而这些本来需求一个完全独立的程序来实现的。.NET的操作代码和执行速度比SQL Server/T-SQL好得多;.NET中的同一位的代码可以运转更快地运转许多次，当它是二进制的，而不是作为存储过程来构建时。

　　使用CLR的另一个巨大的好处就是安全。所有的代码都在运转前检测类型和安全权限。例如，先前没有被写入的内存是不允许被问题中的代码读取的。CLR也很完善;.NET框架中的每样东西都可以从存储过程、触发器或者用户函数进行访问——除了处理类似用户接口的类，它在SQL Server是无论如何不会有用的。

　　要防止CLR代码胡乱运转，微软为CLR代码的调用创建了一个三层的安全模型:SAFE, EXTERNAL_ACCESS 和 UNSAFE。SAFE权限集合在本质上与传统的存储过程能够做的事情一样。在SQL Server之外不能对其进行任何修正。EXTERNAL_ACCESS允许通过.NET对注册表和文件系统进行访问。UNSAFE正如其名。标记为UNSAFE的代码不能做任何事情，并且它实际上是不应该在调试或者实验环境之外使用的。大多数的编程人员应该永远都不需求用到高于EXTERNAL_ACCESS级别的任何东西。(如果你需求在存储过程或者函数的环境中与文件系统或者注册表对话，这有可能意味着你需求重新考虑你尝试的逻辑了。)

　　然而，CLR并不是适合一切。一方面，它可能适合那些不容易、需求进行编程，在T-SQL中实现的环境。许多简单的操作可以在T-SQL以存储过程的方式完成，并且不需求扩展到外部进程。这意味着上下文交换和额外的事务开销，这两项中的任何一项开销都能首先抹消你使用CLR获得的速度提升。CLR最好用于替代扩展存储过程——例如，那些必须封闭在数据库中，但是却非常麻烦，无法用T-SQL从容完成，同时又不能轻松挪动到业务逻辑末尾的事情。

　　另一个可能的缺点就是:正如SQL的领袖Rod Paddock在他的blog中指出的，如果你讲业务逻辑中的某个元素挪动到数据库，那就可能会惹起可测量性的问题。毕竟，SQL Server 更适合于按比例提高的单个大型机器，而不是横跨在几个比较小的机器(通常是按照业务比例来的)上。这一点指出了有选择的使用CLR有多重要。T-SQL简约、无效;CLR/.NET昂贵并且范围广泛。正确的任务选择正确的工具，虽然拥有众多选择也不错。