SQL Server 2005 CLR 功能简介

　　在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 具有扩展性和包容性。正确的工作是采用正确的工具，虽然拥有很多的选择是多么好的一件事情。