在SQL Server 2005的众多被高度评价的特性中，有一个最适合那些对SQL Server编程的人员的就是通用语言运行时，缩写为CLR(Common Language Runtime)。CLR允许编程人员直接在SQL Server 中创建存储过程，触发器，用户定义函数，集合和类型。CLR有很多的承诺，但是它也具有一些缺陷。
CLR的重要性有几个比较大的原因。首先，由于SQL Server编程已经成熟了，编码器运行在SQL Server 自身可能的限制之中，并且很大程度上依赖于外部代码来执行一些繁重的操作。T-SQL (Transact-SQL)在返回数据集合方面非常好，但是在其他方面就不是很好了。CLR使得解决问题和缩减SQL Server内部的数据复制成为可能，通过在SQL Server中需要完全地分离程序来努力实现。.NET操纵代码以及执行速度方面比SQL Server和T-SQL 强得多；.NET中同样位置的代码由于是二进制，因此其运行多次仍然比构建为存储过程快上许多。
使用CLR的另一个巨大的好处就是：安全。所有的代码都是在运行之前检测类型和许可安全的。例如，先前没有被写入的内存是不会被请求中的代码访问的。CLR还非常的完善；.NET框架中的素有的东西都可以在存储过程、触发器或者用户函数中进行访问——除了处理类似用户界面的类，这些类在SQL Server中没有用处。
为了避免CLR的疯狂运行，微软创建了一个三层的安全模型，规定了CLR代码是如何调用的：安全、外部访问和不安全(SAFE, EXTERNAL_ACCESS and UNSAFE)。安全权限设置与传统的可以执行的存储过程一样重要。它不可以被SQL Server自身之外的任何东西修改。外部访问允许通过.NET来访问注册表和文件系统。不安全的命名很恰当。被标记为不安全的代码不能做任何事情，并且他们实际上在调试或者试验环境之外无法使用。大多数的编程人员都不需要使用高于外部访问的东西。(如果你需要在存储过程或者函数的环境内访问文件系统或者注册表，那么很有可能标记着你需要重新考虑你正在做的事情的逻辑了。)
然而，CLR并不适合所有的东西。有一件事，它可能最适合那些不轻松、需要编程的、在T-SQL 中实现的环境。许多简单的操作可以作为T-SQL中的存储过程完成，并不需要做成外部处理。这意味着上下文替换和额外的事务负担，这两项中的每一项都会抵消你使用CLR带来的最主要的速度的提升。CLR用于替换扩展存储过程是最好的——例如，那些与数据库关系密切，但是T-SQL 处理起来过于繁琐的，并且很难轻松地移动到事物的业务逻辑端的。
还有一个可能的不利是:正如SQL 的领袖Rod Paddock 在他的blog里面指出的，如果你将业务逻辑的某个部分移动到更接近数据库，那么有可能引起可测量性的问题。不管怎么说，SQL Server都更适合按比例扩大地放在单个的大型机上，而不是分布在多个较小的机器上(这通常是业务逻辑的测量方式S)。以上指出了有选择地使用CLR是多么的重要。T-SQL 非常紧凑并且有效率；CLR/.NET 具有扩展性和包容性。正确的工作是采用正确的工具，虽然拥有很多的选择是多么好的一件事情。