1、为什么我们必须使用CLR模式来编写存储过程呢?
主要原因是速度。SQL CLR在很多方式下都运行较快:比如字符串处理,它比T-SQL运行快很多,并且对于错误的处理能力也更加强大。同时,由于CLR所提供的来执行这些事务的框架都更为完善,因此任何需要与数据库之外资源进行事务交互的存储过程——比如,文件系统或者Web服务——CLR SP都是表现最好的。
2、CLR最适合编写哪些类型的存储过程?
一般来说,在数据上执行繁重计算而不是仅仅是查询数据的SP最适合用CLR。如果一个CLR SP只是封装一个复杂的SELECT语句,那么我们将无法看到显著的性能增益,因为每次运行SP时,都必须验证CLR中的SQL语句。事实上,它比仅将SELECT语句作为T-SQL SP处理表现还要差。
一个经典的好方法是:如果需要执行的SQL的行数很多,那么可以将SQL封装在一个常规的SP上。如果想要在一个大的数据集上运行CLR风格的处理,那么我们可以在CLR SP内部调用一个常规的SP来获取这个大的数据集。这样,常规的SP会被预编译,性能也会更好,同时数据转换性能也会有所提高。
注意:这种情况是假定我们需要在数据层上进行复杂的数据处理,而不是在显示层上。事实上我们在编写代码之前就需要考虑这些问题。
3、是否应该把现有的存储过程转换为CLR模式?
简单而言,“要有好处才去做”。在这种情况下,可以为指定的存储过程创建一个同等的CLR实现的版本,然后使用实际数据对两种SP进行测试。除非我们可以确定新的存储过程:(a)按照预计的方式运行,(b)对性能有实际的提升,否则应该继续使用老的存储过程。其实CLR跟其它的存储过程一样,没什么奇特的。
4、在没有开发IDE的情况下,可以创建CLR(Common Language Runtime)存储过程吗?
当然,我们可以通过C#编译手动实现这类开发。然而,使用Visual Studio或者类似的IDE可以更简单,特别是当我们在整个企业范围内转换或实现大量SP时。
5、转换有多难?
很明显,我们必须具备其中一种支持语言的知识,如VB.NET或者C#。事实上,SQL命令是“封装”在CLR代码中的,因此,只要我们知道如何使用它,那么在CLR重新实现现有的T-SQL是不难的。比较有难度的是如何使用这种语言来优化我们正在做的工作,这个问题就不是几个要点就可以归纳的。