用.Net开发DB2应用程序比较

　　简介

　　在.net应用软件开发人员看来，使用db2与使用其它任何其它关系数据库没有区别。人们可以看到无数使用sql server以及甲骨文公司产品执行数据库任务的例子，但关于使用包括.net在内的微软公司技术访问db2数据库的文档就远没有那么多了。

　　目前，开发人员可以使用不同的访问技术通过编程的方式将.net客户端连接到db2上，这些代码从根本上来说是基本相同的，但仍然存在一些我们需要考虑的有趣的限制。

　　db2架构慨览

　　db2数据库引擎的基本元素是数据库对象、系统目录、目录和配置文件，所有的数据存取都通过sql界面进行。我们可以只将db2 univeral database（udb）作为数据库服务器运行，这不要求使用其它的产品，但对于远程的客户端而言，我们还需要其它一些产品。

　　db2 udb的服务器组件提供了对使用tcp/ip、sna或ipx/spx协议与数据库服务器进行通讯的支持，这就能够使运行管理客户端、运行时间库或应用程序开发客户端的远程客户端进行访问。应用程序开发客户端组件是面向数据库应用程序开发人员的工具集，它包括库文件、头文件、api和样板代码。

　　我们主要关心的是能够通过网络访问数据库服务器的客户端组件。通过使用db2 connect，我们的.net应用程序能够访问基于主机的db2系统，例如db2 for as/400、db2 for os/390、db2 for vse等。

　　连接到db2的方式决定了我们能够完成的任务。有三种技术可以从.net连接到db2：

　　1、使用oledb .net managed provider。如果运行的是db2 v7或更低的版本以及com对象是调用者时，微软和ibm二家公司都建议使用oledb数据提供者访问大多数db2数据。在.net framework中，oledb提供商是通过com interop表现出来的，并使用可用于ado开发的驱动程序。

　　2、使用odbc .net managed provider。这种方式提供了对本地odbc驱动程序的访问，与oledb .net data provider提供对本地oledb提供者访问的方式相同。odbc .net data provider是.net framework的一个附加组件，它能够与所有兼容的odbc驱动程序配合使用。

　　3、使用ibm db2 .net provider（β）：这种方式提供了对将ado.net连接到db2 v8.1的支持。db2 .net data provider是visual studio .net framework的一个内插式附件，它能够访问在运行在不同硬件和操作系统平台上的db·数据库服务器。目前，它仍然处于β测试阶段，但ibm公司很快会发布正式产品。db2 .net data provider能够将使用ado.net开发的应用程序连接到下面的db2数据库服务器上：

　　·运行在windows、unix和linux平台上的db2 universal database version 8.1。

　　·运行在z/os、os/390 v6.1以及使用db2 connect v8.1组件的更高版本的操作系统上的db2 universal database。

　　不同的连接字符串显示出不同情况下的语法差别：

　　　oledb连接字符串 ...

provider=ibmdadb2.1;user id=db2admin;password=db2admin;data source=sample

　　　odbc连接字符串 ...

dsn=db2v8;uid=db2admin;pwd=db2admin

　　　ibm managed provider连接字符串 ...

database=sample;user id=db2admin;password=db2admin;server=irek

　　代码级访问的比较

　　在开发db2数据访问代码时，大多数的操作在很大程度上与访问其它数据库相同。下面我们对连接技术的一些代码进行比较：

　　在下面的每个代码片断中，我们将展示一些数据库访问和数据管理的技巧，请读者注意每种技术的哪些步骤相同。我们首先创建连接对象，再创建一个命令对象。在这个简单的例子中，我们只访问这一特定数据库表中指定行、列中的一个标量值。最后，我们执行该命令的executescalar()方法，返回该整数。

　　使用ole db技术...

　　private oledbconnection cn = new oledbconnection(connectionstring); oledbcommand cmd = new oledbcommand("select count(*) from staff", cn); int rc = convert.toint32(cmd.executescalar());

　　使用odbc...

private odbcconnection cn = new odbcconnection(connectionstring);
odbccommand cmd = new odbccommand("select count(*) from staff", cn);
int rc = convert.toint32(cmd.executescalar());

　　使用ibm的managed provider...

private db2connection cn = new db2connection(connectionstring);
db2command cmd = new db2command("select count(*) from staff", cn);
int rc = convert.toint32(cmd.executescalar());

　　功能的比较

　　根据选择的访问技术和使用的数据库版本，我们可以使用不同的功能。另外，根据需要完成的工作，我们还需要选择连接策略。

　　为了使读者能够更好的选择连接技术，我整理出了一个能够在决策中使用的路线图。在路线图中，我找出了一些对于大多数以数据库为中心的软件开发项目中通用的功能。

　　在下面的图表中，我对自己的心得进行了整理。我根据是否允许完成特定的数据库任务对三种访问技术中的每一种都进行了评估，评估的数据库任务有：

　　·pass-thru sql━━这一提供者是否支持通过动态开发的sql语句形成的传递？

　　·简单的存储过程━━这一提供者支持包括返回结果在内的调用基本的存储过程吗？

　　·in、out、inout参数━━这一提供者支持调用存储过程和利用参数传递变量数据吗？

　　·日期和货币━━这一提供者支持由特定厂商提供、可能造成问题的数据类型吗？

　　·lobs━━这一提供者支持大对象数据类型的处理吗？

　　根据使用的连接技术，我们能够完成不同类型的任务，因为每种提供者都有自己可以完成的工作。有一些问题是我们值得注意的。

　　例如，odbc不支持db2的存储过程。因此，如果开发的应用软件非常依赖于存储过程，我们在选择访问技术时就不能考虑odbc，而应当考虑oledb或managed provider。oledb不支持lob数据类型，如果要存取lob类型的数据（例如jpeg文件），我们可以使用odbc或managed provider。目前，managed provider不能在db2 v7或以前版本上运行，除非在应用程序和基于主机的db2系统之间运行着db2 connect v8。

　　有趣的是，在使用存储过程的参数时，db2 v7和oledb有一个非常著名的bug。我们能够从存储过程中返回数据，但在oledb+db2 v7平台上，我们不能在应用程序与存储过程之间传递参数。

　　性能比较

　　为了衡量提供者的性能和向读者提供指导，我们将定义一个有效的测试脚本，并对各种提供者的关健性能进行测试。为了比较各种连接技术的性能，我们开发了一些简单的web网页，一个网页面向执行完全相同功能的测试，这将使我们掌握分析不同连接技术情况下输出的控制数据。

　　如果严格地从性能的角度来看，我们发现，managed provider在访问db2数据库时的性能最高。在这一简单的测试中，有二个重要的数字值得关注：每秒钟的请求（rps）能够使我们感受到访问的规模，oledb和odbc在这方面的表现基本相似，但managed provider的表现要好一些（大约高10%左右）；收到最后一字节的时间（ttlb）是从终端用户的角度看到的响应时间，在这一方面，managed provider的性能再次比oledb和odbc高出10%左右。

　　最值得注意的是，尽管提供的功能不同，但oledb和odbc在有负荷的情况下的性能基本相同。ibm公司的managed provider的性能最好，而且提供了在访问db2 v8时最可靠的功能。但是，如果没有db2 connect作中间体，它不支持db2 v7以及更低的版本。

　　结论

　　对于应用软件开发人员而言，使用db2作后端与使用其它通过ado或ado.net访问的关系数据库一样简单。ado.net为我们完成了所有抽象工作。在选择db2还是其它数据库时，尽管存在架构方面的考虑，但作为开发人员，我们的工作应当是可预测和可管理的。