SQL Server 2005与DB2 8.2对比分析(3)

.net 2.0与.NET 1.1的差别

使用.NET框架2.0版结合SQL Server 2005和Visual Studio 2005与使用.NET框架1.1版结合DB2 UDB 8.2相比，有着一些显著的优势。.NET框架2.0版和以前版本相比，功能有着显著的增强:

·改善的性能和装载时间

·支持泛型(同一个类和方法可针对于不同数据类型的值一样运行，因此提高了代码重用性)

·支持“编辑后继续运行”(Edit-and-Continue)，开发人员能够在执行过程中修改代码，而无需中止和重新开始调试会话。

·一个新的数据保护API(DPAPI)，使得应用程序能对某些敏感信息加密，例如连接字符串甚至内存块。

·流的身份验证功能通过新的NegotiateStream和SslStream类允许您使用 Kerberos 或 SSL 来实现客户端和服务器端的安全通道。

·COM互操作性的改善将使得.NET应用程序在调用现存的COM对象时有着更好的性能和可靠性。

·经过改善的I/O性能加上对GZIP数据压缩的支持

·64位应用程序兼容性

部署.NET逻辑到SQL Server

每个数据库平台实际使用.NET对象的方式也是有着很大差别的。在SQL Server 2005中，一个新的SQL Server数据库对象程序集(Assembly)是部署.NET对象(例如触发器或是存储过程)的最小单元，程序集组是部署.NET逻辑的最小单元。为了创建CLR数据库对象，你必须首先使用Visual Studio 2005创建一个DLL。接着将这个DLL导入到SQL Server中作为一个数据库程序集对象。这些步骤能够使用命令行编译器和CREATE ASSEMBLY命令手工实现，或者像在技术演示部分里所看到的一样，Visual Studio 2005能自动完成整个流程。

SQL Server中Assembly的安全

SQL Server 2005给数据库管理员提供了一个新的安全单元——程序集。程序集可被标记为三种安全状态:SAFE、EXTERNAL和UNSAFE。这些安全标号供数据库管理员用来管理和保护所有在数据库里以程序集级别运行的.NET代码。SAFE标号表示这个程序集只使用托管代码并且不访问数据库之外的资源。EXTERNAL标号表示这个程序集使用托管代码访问外部资源，例如文件系统或是网络等非数据库之内的资源。UNSAFE标号表示这个程序集能够包含托管和(或)非托管代码，并且能够访问任何内部或外部的资源。由UNSAFE程序集创建的数据库对象只能被拥有系统管理员权利的用户执行。

部署.NET逻辑到DB2

虽然将.NET托管代码装入DB2 UDB 8.2的流程与装入SQL Server 2005的流程很相似，但在数据库对象类型和存储位置以及安全和数据库管理流程方面还是有着一些差别。为了创建DB2中的CLR数据库对象，你得首先使用Visual Studio并采用某种.NET托管语言创建一个DLL，这个DLL文件需要拷贝到DB2安装路径专门的目录中去，或者在创建存储过程或者函数的时候提供这个DLL文件的完全路径。这个DLL实际上不是一个数据库对象，也没有被导入到数据库表中，相反，它只是一个操作系统中的文件。接着，这个DLL将出现在创建数据库对象(例如存储过程或者函数)的CREATE命令中。在技术演示部分中，你将会看到使用Visual Studio 2003能够自动完成创建DB2 CLR存储过程的整个流程。不过，创建用户定义函数则不一样，你只用通过手工来完成创建用户定义函数的流程。

一个数据库管理员或者是一个应用程序开发人员通常需要保护与DB2外部程序相关的DLL程序集，这可以通过限制程序运行时的操作来实现，这步工作在创建过程或函数时，在CREATE语句的EXECUTION CONTROL子句中完成。有效的执行控制模式包括:SAFE、FILEREAD、FILEWRITE、NETWORK和UNSAFE。如果没有指定执行控制模式，默认模式是SAFE，这将意味着这个CLR程序只能访问由数据库管理员控制的资源，这样的资源包括所有的表和由数据库实例管理的架构。FILEREAD、FILEWRITE和NETWORK执行模式允许托管代码访问本地文件系统或者是网络上的资源。UNSAFE执行模式将不会在资源访问上做任何限制，标记为UNSAFE执行模式的程序可以执行二进制代码。既然DB2与.NET的集成采用的是“进程外”的模型，那么在使用CREATE语句创建DB2 CLR过程和函数时必须采用FENCED子句，用以说明.NET逻辑和数据库管理器在不同的进程中运行并且不使用共享内存通讯。这就造成了在程序逻辑与数据库本身之间传输数据的时候，与“进程内”模型相比，有一个性能上的障碍。