在SQL Server 的许多被大力推荐的特性里面有一项可能对那些使用SQLServer 工作的编程人员最实用的是Common Language Runtime或者简写为CLRCLR可以让编程人员直接在SQL Server中创建存储过程触发器用户自定义函数集合体和类型CLR有很多的承诺但是也有一些缺陷
关于CLR的重要性有一些主要的原因首先随着SQL Server 编程技术的成熟代码编写人员陷入了SQL Server自身的一些限制之中并且在很大程度上依赖外部的代码来执行一些繁重的移植TSQL (事务处理SQL)在返回数据集方面很好但是除了这个之外则表现不佳CLR使得问题的解决有了可能并且在SQL Server内部进行数据操作而这些原本需要一个完全独立的程序来实现的NET的操作代码和执行速度比SQL Server/TSQL好得多;NET中的同一位的代码可以运行更快地运行许多次当它是二进制的而不是作为存储过程来构建时
使用CLR的另一个巨大的好处就是安全所有的代码都在运行前检测类型和安全权限例如先前没有被写入的内存是不允许被问题中的代码读取的CLR也很完善;NET框架中的每样东西都可以从存储过程触发器或者用户函数进行访问——除了处理类似用户接口的类它在SQL Server是无论如何不会有用的
要防止CLR代码胡乱运行微软为CLR代码的调用创建了一个三层的安全模型:SAFE EXTERNAL_ACCESS 和 UNSAFESAFE权限集合在本质上与传统的存储过程能够做的事情一样在SQL Server之外不能对其进行任何修改EXTERNAL_ACCESS允许通过NET对注册表和文件系统进行访问UNSAFE正如其名标记为UNSAFE的代码不能做任何事情并且它实际上是不应该在调试或者实验环境之外使用的大多数的编程人员应该永远都不需要用到高于EXTERNAL_ACCESS级别的任何东西(如果你需要在存储过程或者函数的环境中与文件系统或者注册表对话这有可能意味着你需要重新考虑你尝试的逻辑了)
然而CLR并不是适合一切一方面它可能适合那些不容易需要进行编程在TSQL中实现的环境许多简单的操作可以在TSQL以存储过程的方式完成并且不需要扩展到外部进程这意味着上下文交换和额外的事务开销这两项中的任何一项开销都能首先抹消你使用CLR获得的速度提升CLR最好用于替代扩展存储过程——例如那些必须封闭在数据库中但是却非常麻烦无法用TSQL从容完成同时又不能轻松移动到业务逻辑末尾的事情
另一个可能的缺点就是:正如SQL的领袖Rod Paddock在他的blog中指出的如果你讲业务逻辑中的某个元素移动到数据库那就可能会引起可测量性的问题毕竟SQL Server 更适合于按比例提高的单个大型机器而不是横跨在几个比较小的机器(通常是按照业务比例来的)上这一点指出了有选择的使用CLR有多重要TSQL简洁有效;CLR/NET昂贵并且范围广泛正确的工作选择正确的工具尽管拥有众多选择也不错
