簡介

　　在.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還是其它數據庫時，盡管存在架構方面的考慮，但作為開發人員，我們的工作應當是可預測和可管理的。