本文對SQL Server 2005與DB2 8.2這兩種數據庫平台進行對比，結果顯示在構建數據庫應用程序時，使用SQL Server 2005(代碼代號“Yukon”)結合Visual Studio進行開發比使用DB2 UDB 8.2(代碼代號“Stinger”)結合Visual Studio有著顯著的優勢。
對比結果概述
本文中對兩種數據庫平台的對比結果顯示了在構建數據庫應用程序時，使用SQL Server 2005(代碼代號“Yukon”)結合Visual Studio進行開發比使用DB2 UDB 8.2(代碼代號“Stinger”)結合Visual Studio有著顯著的優勢。在開發、調試和部署數據庫解決方案的時候，這些優勢就將轉化為在時間和資金上的節省。在本文中特別說明了SQL Server 2005與DB2 UDB 8.2相比，對.Net數據庫對象的支持要廣泛的多。另外，你會發現在構建和管理數據庫對象時，SQL Server 2005和Visual Studio集成的程度要比DB2 UDB 8.2和Visual Studio的集成緊密的多。在本文中，你還會看到SQL Server 2005所提供的開發平台除了關系型數據庫之外，還有其他許多功能，這一點超過了DB2 UDB 8.2。
前言
在過去，IT開發技術分成了程序開發語言、產品環境配置和數據操作這三種相對獨立的專業技能。為了綜合使用這些相對獨立的技能往往需要專門的技術和大量的人力。現在，有了SQL Server 2005和Visual Studio 2005，我們擁有了一個統一的開發環境，集成於其中的編程模型提供了整體的解決方案，包容了客戶端數據庫應用程序、服務器管理工具和服務器端數據庫對象的構建。如此對工具和框架功能性的改善將使得開發者和客戶都能從中受益，因為它將會對應用程序的可用性、性能、安全性和可伸縮性帶來一個全面的提升。
SQL Server 2005和DB2 8.2中對Visual Studio環境和數據庫數據提供程序的集成將簡化和改善應用程序的開發流程。它們提供了旨在提高生產率的構建和部署應用程序的工具，這將會給程序開發和應用程序管理帶來更好的性能表現。SQL Server 2005和DB2 UDB 8.2中對.Net框架的集成帶來了一個更加高效和更加靈活的數據庫應用程序開發環境，由此得到了比先前版本執行效率更高的更加健壯的數據庫解決方案，它擁有更好的易用性和可伸縮性。通過利用集成的.NET環境，數據庫開發人員就可以實現以前使用SQL代碼不可能得到的結果。通過使用.NET框架，開發人員寫出的代碼能具有更加復雜的邏輯，更加適合於解決計算問題，並能訪問到外部的系統和網絡資源，因為.Net語言，例如Visual Basic、C#和C++，都是完全的面向對象編程語言，具有像封裝、繼承和多態性這樣的面向對象編程的特性。它們還具有許多在SQL語言中不存在的功能，例如數組、結構化異常處理、集合等。
如今，Microsoft .NET提供了最先進、最高效的構建和整合數據庫應用程序的環境。在這篇文章中，我們將比較SQL Server 2005和DB2 UDB 8.2分別提供的.NET集成的程度。為了能充分說明這其中的差別，我們將做一個詳細的技術演示來顯示分別使用SQL Server 2005和DB2 UDB 8.2構建一個.Net存儲過程的具體步驟。
核心技術比較
雖然SQL Server 2005和DB2 UDB 8.2都集成了.NET框架和Visual Studio，但各自的集成程度有著顯著的差別。下面這張表格中列出了關於它們對.Net的集成程度的比較。
數據提供程序
SQL Server 2005和DB2 UDB 8.2都自帶了.NET數據提供程序，使得.NET客戶端程序能夠訪問數據庫平台。這些“天生的”數據提供程序與基於OLE DB的數據提供程序相比，會給服務器應用程序帶來更好的性能和可伸縮性。這兩種數據提供程序有著非常相似的功能，都能執行基本的ADO.NET對象，包括Connection、Command、DataReader、DataSet和DataAdapter。但它們有一個關鍵的差別:SQL Server .Net數據提供程序有兩種模式可用，一個針對於客戶端應用程序，另一個針對於服務器端應用程序。這一點對於服務器端應用程序開發特別重要，因為SQL Server服務器端.NET數據提供程序是一個駐於內存的程序，它不用像客戶端數據提供程序那樣去考慮網絡流量的限制，因此，服務器端.NET數據提供程序能針對.NET數據庫對象實現更好的性能。另外，服務器端數據提供程序還開放了一組只適合於服務器端代碼的功能，例如服務器端游標。針對客戶端應用程序的數據提供程序所開放的功能在System.Data.SqlClIEnt命名空間中，而服務器端數據提供程序所開放的功能在System.Data.Sqlserver命名空間中。在DB2 UDB 8.2中，只有單獨的IBM.Data.DB2命名空間。DB2 .Net數據提供程序使用DB2Context對象來創建駐於內存的數據庫連接。
在服務器端，它們同樣有相似之處。DB2和SQL Server都支持使用.NET語言構建應用程序以及隨後在服務器端部署。其實除了這一基本概念，這兩種數據庫平台對.NET的集成程度有著很大的差異。DB2 UDB 8.2支持創建.NET存儲過程和.NET用戶定義函數。可是，Visual Studio IDE只支持創建DB2 UDB 8.2 .NET存儲過程，DB2 UDB 8.2 .NET函數必須手工創建。與之相比，SQL Server 2005對.NET的支持要廣泛的多。和DB2一樣，SQL Server支持創建.NET存儲過程和.NET用戶定義函數。除此之外，SQL Server還支持.NET觸發器、.NET用戶定義類型(UDT)以及.NET用戶定義聚集。所有這些對象的創建都被完全集成到Visual Studio 2005 IDE中了。能使用.NET語言構建存儲過程和函數對數據庫開發人員來說肯定是個好消息，這將使得他們能夠實現更加復雜的商業邏輯和函數功能而不必受限於標准SQL的功能。這一點無疑是將.NET與數據庫集成的關鍵所在，當然，使用.NET語言創建觸發器、用戶定義類型以及用戶定義聚集也很有用。使用.NET語言創建觸發器將使得觸發器的代碼能更加完全地封裝商業邏輯，同時還能執行一些附加的操作，例如訪問外部資源記錄操作日志。使用.NET語言創建用戶定義類型能使得數據庫開發人員能擴展系統中原有的數據類型，這些用戶定義類型能擁有自己獨立的屬性和操作符，這使得開發人員可以無縫地擴展原有的數據類型，在使用的時候就和原有的數據類型一樣，具有各自的操作符和聚集。同樣地，使用.Net創建用戶定義聚集使開發人員能創建自定義的聚集操作應用於原有的數據類型或是用戶自定義的數據類型。
除了這些基本的.NET功能，在.NET框架與各自的數據庫服務器集成方面還有重大的差異。在下一部分中，我們將更深入地討論.Net集成的細節。
.Net框架集成
Microsoft® .NET是用來把信息、人力、系統和設備聯系在一起的一組Microsoft軟件技術。.Net框架是構建和運行下一代軟件應用程序和Web Service所必需的Windows組件。
.Net框架
◆支持超過二十種不同的編程語言。
◆管理著大量的“管道”——有助於提高軟件開發效率並使得開發人員的精力更加集中於核心商業邏輯代碼上。
◆使得構建、部署和管理一個安全的、健壯的以及性能卓越的應用程序比以前更加容易實現。
.NET框架由公共語言運行庫(CLR)和統一分層的類庫集合所組成。.NET CLR的職責主要包括集成語言的運行服務、強制安全性和對內存、進程以及線程的管理。在語言集成方面，CLR定義了通用類型系統(CTS)，它描述了跨越所有.NET語言的基本數據類型以及關於那些數據類型的操作。.NET框架提供了大量的類集供開發人員應用於他們的應用程序中，這些類集涵蓋了很多方面的內容，包括I/O、網絡、文本處理、數據訪問、加密、XML處理、Web Service等等。這樣就允許開發人員能把精力主要集中在構建商業邏輯上而不是埋頭於“管道”代碼中，因為這些能在.NET框架的類集中找到。SQL Server 2005和IBM DB2 UDB 8.2中對.NET CLR的集成使得可以用任何一種.Net語言(包括C#、Visual Basic、C++以及J#)來開發數據庫對象。
這兩種不同的數據庫平台和.NET框架集成的方式是完全不同的。SQL Server 2005數據庫引擎將CLR宿於進程內，這意味著同時運行數據庫引擎和.NET運行庫只需要一個獨立的操作系統進程。與之相比，DB2 UDB 8.2和.Net框架的集成采用的是“進程外”的模型。圖1對不同的數據庫CLR實現方式進行了直觀描述。
集成模型的含意
SQL Server 2005集成.NET運行庫時采用的“進程內”模型與“進程外”模型相比有一些非常明顯的優勢。首先，將CLR集成在進程內部使得SQL Server能以不同的方式控制CLR的運行。內存管理、垃圾收集器、線程支持的核心功能將受到SQL Server主機的控制，而不是采用.Net的默認設置和操作。這一點非常重要，因為SQL Server數據庫引擎能更好地從整體的角度來考察系統需求，從而使得它能根據實際情況優化內存和線程的管理。最終，以“進程內”模型集成CLR的SQL Server 2005能創建得到更加健壯和有更好伸縮性的解決方案。
舉個例子，考慮一個負擔沉重的數據庫實例，要響應許多並發的請求，這一情況已經持續了很長一段時間。SQL Server能自動和智能地在數據存儲和程序邏輯(例如，.NET存儲過程)之間平衡內存的分配。當系統的負擔有了一些性質上的變化——例如，相對較多的請求利用了較多的程序邏輯——SQL Server會再次自動地進行調整。這樣，系統的性能會根據滿足實際需求的伸縮性和可靠性進行不斷的優化。因為DB2 UDB v8.2采用“進程外”的模型集成.Net運行庫，所以DB2不能提供這種類型的機器資源動態平衡和性能優化。
SQL Server 2005是通過使用CLR 主機API來實現動態優化的，這些API只在.NET框架2.0版中存在，而在.NET框架以前的版本裡是沒有的。必然的結果，SQL Server 2005需要集成.NET框架2.0版而DB2集成的是.Net框架1.1版，集成的程度自然較低。
.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邏輯和數據庫管理器在不同的進程中運行並且不使用共享內存通訊。這就造成了在程序邏輯與數據庫本身之間傳輸數據的時候，與“進程內”模型相比，有一個性能上的障礙。
