關於此白皮書
在此白皮書中描述的這些特性及計劃是SQL Server下一版本的發展方向。它們不是這一產品的說明書而且也建議在使用中有所變更。在此不作出任何保證，暗示或其它，這些新特性將會包含在最後產品發行書中。
對於某些新特性，此文檔以讀者熟悉SQL Server 2000的性能和服務為前提。若您擁有SQL Server性能和服務的背景， 讀者可以參見正式產品的網站：http://www.microsoft.com/sql/ 或者在Microsoft 網站上獲取SQL Server資源工具包。
此白皮書會提供相關信息使得數據庫管理員能夠成功的，沒有風險的，沒有壓力的在數據庫引擎中確保Microsoft .Net Framework編程的使用。因此，此白皮書的讀者應該是數據庫管理員。 作為一個使用SQL Server 2005數據庫引擎且具有遠見的開發者，您可以登錄MSDN 中題目為 Using CLR Integration in SQL Server 2005的白皮書以學習更多知識。
為工作尋找正確的工具
Microsoft® SQL Server™ 2005 提供一套完整的程序接口，使得開發者可以比以前更加輕松，更易操作的，更具可靠性的構建完善的數據庫應用程序。隨著大篇幅的程序選項而來的是為每個任務提供整套適當工具的考量的需求。雖然很多任務可以用很多方法完成，但每種方式都有其優勢和弊端。因此，為工作找尋最好的工具的標准在於應用程序在商業使用中的加載和使用的程度。數據庫管理員可能會有意下一些問題：
◆系統是否應該用XML處理數據或者刪除和存儲是否應該相關聯？
◆這些過程和這些過程復雜的操作步驟是否應該被同步或異步處理？
◆這些商業邏輯，計算或額外的安全選則是否應該在客戶應用程序，中間層或後台數據庫中被處理？
◆數據分析是否應該在關聯數據庫中或者通過商業整合引擎來處理？◆數據轉變是否在智能服務ETL 引擎裡發生或者是在SQL處理數據庫裡來轉變？
◆傳統運行在中間層服務器中的復雜商業邏輯是否仍然在中間層或是移動至SQL Server平台？
◆怎樣混合的客戶及服務器在infrastructure 中運行。是否需要Windows客戶端，Unix 客戶段的支持，還是兩個均需要？
在大多數數據庫開發項目中，與數據庫相互影響的技術選擇和組件結構化設計的角色落到了數據庫管理員（DBA）的身上。這個管理者就是管理和恢復商業數據擁有最終職責的那個人。大多數數據庫管理員們對新技術采取保守態度。這是一個本能，因為同新功能提供的好處隨之而來的是，新技術可能包括危及穩定性和完整性的新風險。經驗豐富的數據庫管理員 經常通過全面的測試和對新技術的理解來為管理風險/利益作出保證。而且更多的是，他們常常花時間來確定哪裡加入更值得，或者更重要的是，哪裡不能被使用。因此在本能的保守主義作用下，數據庫管理員可能會問：“當我明白了這些特性我怎麼將它們關掉？”好消息是早前發布的SQL Server ，這回發布的版本在默認情況下新特性是關掉的。
與那些將新特性永久關閉的人不同的是，一個謹慎的數據庫管理員 將會注意學習足夠的技術來決定它可以在哪裡被適當的使用以及哪裡可以使它發揮最大作用。完全不需要理解開發者可能會使用到的每一個語言裡的每一行代碼，但是你確實需要足夠的信心來提供非常多的操作支持，維護和排錯。 在這些新特性的圍繞下，適當使用它們的關鍵在於理解力，分析能力以及強的控制力。
在數據庫引擎中.Net Framework編程的初步介紹
當SQL Server數據庫表和視圖不許編寫代碼時，SQL Server 2000數據庫程序員擁有如下選擇：◆在數據庫中使用Transact-SQL 編寫代碼。代碼可以被寫為存儲過程，用戶定義功能，也可以將觸發器看作調用數據變化的已存儲的過程。
◆使用Microsoft® Visual C++® 來編寫代碼，可以在數據庫中運行。被寫為一個擴展存儲過程的代碼在用戶表面上看來是一個存儲過程，且以同樣方法運行。Parameters can be passed to參數可以被傳遞給擴展存儲過程，而且他們可以參與事務的處理以及返回結果和狀態。
◆使用sp_OA* (Object Access) 使用COM對象加載和影響系統存儲過程。
◆使用其它語言和中間設備，例如ADO 和ADO.Net， 用他們來編寫在數據庫外執行代碼，然後在查詢語句中查詢或者調用存儲過程和功能來訪問數據。passes in querIEs or invokes stored procedures and functions to Access data.
當解決方案要求用外部庫提供數據在具有功能性的前提下是完整的時，每個選項都有不同作用。例如，有些選項是選擇由.Net Framework提供,或者有些是選擇將復雜數學運算應用在數據上，再或者是更多復雜性的需求，例如一個客戶數據集或一個真實的使用者定義數據類型。
這四個選項每一個都有限制：
◆Transact-SQL對於操作的基本設置是最好的，例如在表之間作比較，但是由於口語的限制，它為繁重任務量的可估測性的傳送帶來了障礙。另一個限制是不同於現代編程語言，Transact-SQL 不能夠支持私有/共有數據封裝，因此對他來在模塊間清除接口說是比較困難的。 最後， SQL Server 2005在Transact-SQL中引進了改良的錯誤處理機制。然而，它仍然易受那些由丟失對象或錯誤語法所引起的不可引導的錯誤所影響，但這些錯誤在.Net Framework語言中是很容易解決的。
◆擴展存儲過程是很自然地被編寫在不可管理的代碼中且在SQL Server進程中執行。高級別的編程能力是在不關注內存漏洞的情況下創建SQL Server進程完整的代碼。擴展存儲過程不可以提供在進程中狀態時不支持狀態中對Microsoft .Net Framework 庫的訪問。 想得到更多信息，請登陸題目是Using extended stored procedures or SP_OA stored procedures to load the CLR in SQL Server的基礎知識文章。在這裡並不提供。◆sp_OA* 系統存儲過程空間在COM上是有限制性的。它要求它的接口是在兼容的方法上執行，在單獨調用的COM對象上有更加嚴格的數據限制。它們鼓勵使用不相稱組件，而且它們沒有被設計為可以使用高吞吐量，或者不支持在單一進程中使用多重調用。在最壞的情況下，組件可以試著顯示一個錯誤消息界面或者在SQL Server上顯示其它對話框。
◆外部代碼可以導致操作問題，因為數據必須留給SQL Server 進程空間而且需流動至應用程序呼叫。這個數據組可能占用大量數據集。
◆目前的選項沒有可以用來創建first-class,客戶聚合功能 functions or custom data types where first-class means running within the database as if it were a SQL Server primitive function or data type.首要級別的函數或者用戶數據類型意味著在數據庫上像原始的函數和數據類型一樣的運行。
由於以上的局限，SQL Server 2005整合了.Net Framework 通用語言運行時（為管理代碼提供執行環境）因此，數據庫開發者能夠可以將以管理好的應用程序代碼安放在SQL Server中，這樣做是安全，保險，可升級和多特色的。代碼可以按以下方式寫：
◆用戶定義功能（標量 或者表值）
◆存儲過程
◆觸發器
◆用戶定義聚合
◆用戶定義類型
對於對象的用戶定義功能的映射, 存儲過程，以及觸發器都在管理代碼裡編寫，這樣做是非常直觀的。CLR程序像應用Transact-SQL一樣的被訪問和執行的。然而, 用戶定義聚合和類型是非直觀的， 數據庫程序員可以用新的方法選擇擴展選項：
◆用戶定義聚合允許程序員建立習慣性聚合函數(用GROUP BY子句來關聯). 這可以在數據庫引擎中進行復雜統計和數據分析。
◆用戶定義類型為程序員提供用習慣性行為定義新類型的權限。綜合.Net Framework 的能力和第三方庫，這個新型能將會允許強大的類型對象被創建而不是形成關聯陳述。高性能執行
SQL Server 2005向 數據庫服務器進程中的已管理的代碼傳遞高性能訪問，與其它數據庫技術不同的是，它提供.NET Framework 綜合度，SQL Server 2005管理數據庫引擎進程空間中的運行時環境（CLR）。使得SQL Server 查詢執行環境具有更高的性能。而整合功能被設計出來是為了在數據庫查詢和編程時避免內存和CPU沖突。另外, the SQL Server和.Net Framework 軟件工程師們致力於使CLRSQL Server 進程中更安全和更好用。
◆CLR 向SQL Server提出內存請求，而不是直接從Windows中申請。
◆CPU加強器CLR內存 通過SQL Server回收資源。
◆一個在進程中的version of the被管理的SQL Server 客戶通過SQL 要求直接進入SQL Server 查詢進程器, 因此應避免昂貴的網絡交互作用。
◆CLR 應用程序域被SQL Server創建及管理。
被設計出來的所有的工程是為了確保失控的CLR程序不可以危及SQL Server的可靠性。
設計，默認及部署方面的安全
Microsoft 致力於為其客戶提供安全的產品。例如，SQL Server 2000 SP3中提出的信任計算。這種設計將作為微軟產品更進一步增前“off by default”默認安全的理念將進一步影響SQL Server。
注意 數據庫引擎.Net Framework 編程 API 是默認關閉的， 且數據庫管理員 必須進行一些操作來激活這一功能。
SQL Server 2005 引入了Surface Area Configuration 工具，它被激活後能夠由數據庫管理員 來控制。這一改變可以確保那些潛在的人們不習慣使用的功能不被激活且被遺留為不被保護狀態。
步驟1: 打開Surface Area Configuration 工具
圖 1The 此工具的快捷方式被安裝在SQL Server 2005程序組的配置工具sub-group 中的Start/All 程序菜單。
選擇SQL Server Surface Area 配置選項然後選擇 Surface Area Configuration for Features選項。
這樣將會打開一個對話框在它下面激活一個SQL 服務器實例選項，然後是均鎖定的選項
步驟2: 激活數據庫引擎.Net Framework 設計 API
選擇Surface Area Configuration for Features opens the dialog below. 將出現兩個視圖：通過SQL Server默認（通過實例）激活選項，第二個是通過組件激活選項例如數據庫引擎和報表服務。
在激活這些功能前，增加SQL 服務器的 的外表區域,推薦數據庫管理員確保他們的系統遵從以下幾點：
◆最新的服務包和關鍵的熱修補包 (可由 Microsoft Update獲得)
◆配置遵從他們的推薦以使系統更安全 (這些也可以由其他的針對服務器和基礎架構的第三方工具來配置)
圖 2
數據庫引擎 .Net Framework 設計API是數據庫引擎特性趨勢，且把它以CLR 整合到用戶界面中。
用戶界面為浏覽和設置SQL Server 2005實例層權限提供了一個簡單的方法。SQL Server 2005實例層特性也可以被以下命令控制：
◆Transact-SQL sp_con圖 命令
◆使用服務器管理對象(SMO)服務器對象配置類管理代碼
用Transact-SQL激活API
-- Enable & Check the Database Engine .Net Framework 編程 api
sp_configure N'clr enabled', 1
go
reconfigure
go
SELECT sc.*
FROM sys.configurations AS sc
WHERE sc.[name] = N'clr enabled'
為工作選擇正確的工具工具和API的選擇取決於其他因素例如你內部員工的技術水平，depend on many other factors such as the skills of your internal staff, the recommendations of the 第三方軟件廠商為你公司運行系統的推薦，系統的需求等等。
圖 3
以上插圖顯示出了每一個數據庫管理員都將面對的進退兩難的選擇。 有些選擇是很簡單的但是有些選擇是非常復雜的,特別是當有很多方法都可以實現這些功能時，而且在技術選項之間也沒有絕對的說明。
在這些情況下，原型就顯得愈加重要。一個快捷的執行方法使用兩種或兩種以上的選項，這樣可以使選擇更加清楚。
根據以前的經驗, 經驗豐富的數據庫管理員是保守的。同樣的, 新技術不可能很輕松的就實行起來；他們必須首先被理解然後在他們完整引進至生產環境前需要進行嚴格的測試。另外，冒著動搖數據庫的危險而導致用戶對數據庫管理的系統完整性不信任，可能會威脅到數據庫管理員工作的安全。一個長遠的假設是開發者會更加期望捕獲風險和采用新工具來提高他們的生產力，以及擴大他們的知識面寬度，以幫助他們可以為用戶提供的更多的解決方法。數據庫引擎.Net Framework 編程模型具有強大功能是毫無疑問的，很多數開發者將會感激這項在數據庫中以第一類編程語言寫代碼的新功能。
因此，在保持系統的穩定性和獲得更大的生產力著兩者之間就出現了矛盾。那麼如何處理這個矛盾哪？
答案就是找到平衡，理解時機，然後更加著重於理性的定義選擇，基於嚴格的標准做技術選擇。這個章節給出了一些指導方針，送而找到一個折中的平衡點。
第一組觀點就是在可能出現錯誤的地方使用新功能提供指導：◆深度相關的數據訪問
不要將簡單的查詢執行移出Transact-SQL。Transact-SQL 基本設置訪問將會比在.NET Framework中移進移出數據更快速，特別是基本設置查詢被類指針所代替。排錯包含了此種潛在信息可能的花費。應該注意那些相反的請求，那些被查詢所替代的復雜的計算，在這種情況下，將邏輯移動到.Net Framework程序裡，在那裡計算將被完全編譯，邏輯可以明顯改善。
那些簡單的計算和基本的關系型數據訪問在Transact-SQL和.Net Framework執行環境之間轉換所需的花費是很明顯的。在這樣的情況下，Transact-SQL很可能將會勝過CLR。
◆長時間與轉,外部呼叫
While it is tempting to use the new functionalityt檔使用新功能的同時可以更進一步的與現有的商業系統結合是很具誘惑力的,花費時間來確保最終用戶在呼叫外部API和外部系統時的花費不會得到消極的影響是非常重要的。這些影響可能在用戶定義功能裡特別的明顯，他們可能會導致對表的每一行查詢。在應用於一個10,000-row表時，外部呼叫可能在在線系統中從每秒一行的狀態突然變成不可用的。
◆不必要使用用戶定義類型
當對象數據可能被簡單的映射成一個一隊奪得關聯數據類型，你可以中止或繼續相關。用戶定義類型有以下幾種：
◆8-K大小約束。他們必須適合單一SQL Server數據頁。
◆如果進行更新時，在UDT中的所有數據是可讀和可重寫的。
，當連接大隊列對象時，應該擔心同樣的大小約束會被應用於用戶定義聚合。
◆用戶定義聚合以及在線支持
用戶定義聚合不可以與SQL Server 索引師徒倆和使用，因為為在線報表操作來自動整合數據是不可能的。 如果狀態數據是可接受的，然後，由定期的緩存聚合所產生的結果是一個分離的可創建和可維護的表，它可以被一個索引視圖替代。◆與早期SQL Server版本兼容
如果你的應用程序必須支持早期的SQL Server版本，你不可以使用此功能。
◆適當的使用技術
數據庫引擎 .Net Framework 編程 API 為數據庫程序員引入了很多新可能性。然而, 你可能會避免草率的使用這個新功能除非你可以清楚地了解它使用的基本原理。
這些觀點可能看起來像是為不發展技術提供了一個很有利的實例。然而, 這有很多強有力的例證可以證明很多值得思考的優點。他們包括以下這些：
◆.Net Framework和the Visual Studio編程環境的槓桿作用
這是獲得大多數利潤的關鍵所在，它們以開發者的生產力和新興事物形式被獲取。
在SQL Server 2005和 Microsoft® Visual Studio®2005這代中, 整合開發環境和.Net Frameworks是他們第二代的第三版， 它允許了一個重要的開發者回饋。也就是說使用者接口能夠快速應用開發，而且類庫提供了一整套大量的對象和方法使得開發者可以不用花費力氣來編寫大量的普通任務。
.NET Framework (C#, Managed C++, and Visual Basic.Net)的第一類編程語言提供給程序員更多的對錯誤處理的控制也為訪問堆棧和其他調試信息提供了更好的診斷。
在不需要提升權限的情況下程序員有權使用大多數本地功能，也就說例如大量的XML, 數組，常規表達式，數據功能操作等等都是可被訪問的且不會威脅數據的安全。
另外, 因為這些代碼是編譯然完成的，他們已經被轉換成機器語言，所以在執行業務邏輯的時候會比Transact-SQL更快。
舉例可能會在以下幾種情況下出現：
在表格樣式裡連接遠程網站服務來訪問數據 (在數據層裡為web服務整合更加清晰的權限)
◆基於數據庫中的改變，調用第三方廠商控制，來添加一個ERP系統。◆為了你的商業用途調用代碼庫中提供的數據類型和函數。例如你的研究，商業，銷售的需求。
◆替代擴展存儲過程 (XPs)
在數據庫引擎 .Net Framework 設計 API到來之前, 提供外部世界使用權的唯一方法是通過擴展存儲過程和sp_OA* 存儲過程。 然而, 早期文件證明，即使由經驗豐富的開發者使用，這種方法具有仍對數據庫穩定性極具威脅性。
推薦那些擁有提供外部商業邏輯的擴展存儲過程系統或者那些通過sp_OA*存儲過程使用對象模型操作的數據庫管理員考慮趕快采用這種新技術，因為 SQL CLR 更加安全。
使用SQL CLR有以下優勢：
◆不會因為用戶代碼的錯誤導致SQL Server服務發生故障的情況。
◆沒有發生管理用戶代碼內存漏洞導致SQL Server減速或暫停的可能性。
◆通過SQL Server’s內存管理器控制系統資源更具操作性和可測量性。
◆不會出現安全故障，因為它完全整合了SQL Server和 .Net Framework 環境的安全。
這個優勢可能不會在不安全情況下的程序集注冊中應用， 因為他們可以調用不可控的代碼或者線程庫（例如對話產生代碼，線程創建代碼或者干涉進程關聯處理的代碼。）或者因為他們使用COM自動操作。此外，通過引起違法訪問或者內存漏洞，他們可能仍然對SQL Server 實例有影響。
大多數擴展存儲過程可以被替代，特別是考慮到 C++ 是一個可利用的代碼編寫工具。
◆數據更新確認
為多用戶共同改變數據強制指定一個商業規則是許多系統一直面臨的一個問題。新的API允許這些邏輯在數據庫隊列中移動觸發器來確保所有更新是一致的。
一個例子可能會要求以特別的順序引入數據，而其中的一些系統和技術是通常是不能直接被Transact-SQL觸發器訪問的。觸發器可以檢測出一個新的用戶是不是第一次進入，是不是一個來自遠程的可信任的IBM大型機系統。他可以為所有的商業用戶提供風險管理。◆減少網絡通信量
一些運算法則要求所有或者大比率的數據產生結果。然而，在服務期間移動大量數據是非常消耗CPU資源的。因此，好的算法可以降低數據對CPU的消耗和對網絡的消耗。也可以使應用程序有更好的性能。
例如這可能影響以下的內容：
◆統計計算需要所有數據以產生輸出結果。
◆在SQL的數據集要連接到一些非關系型數據庫時，連接服務不可用及SQL上的數據比遠程服務器上的數據更大時。
◆寫入常規目的函數
一個整合意圖功能具有記下幾個特征：
◆數據以論據行為傳遞。
◆針對內部函數存在很少或者沒有額外的數據訪問。
◆復雜的計算通過是一個循環中的數據的類指針代碼被應用的，它是每次處理一行。
在CLR執行環境下編譯開銷與環境之間轉換所花費的消耗相比更具有優勢，在性能測試中，SQL團隊測試出大約每個調用三個整形操作的降低。
實例中包括了模擬每日的事務處理量，以及一些不長用的數據模擬。
◆標量工具, 用戶定義類型
雖然大多數數據可以被映射為關系模型，這裡仍然有很多例子表現出用戶自定義數據類型需要值得考慮的地方：
◆此類型約束的外部行為是為了使它被SQL Server所接受。一個實例就可以是一個表現了UTC 功能的日期類型。
◆此類型使用了封裝來保護它的內容及數據經常被一起讀和更新的位置。一個實例也可以是一個的空間的數據類型或者一個復合數字的執行。
◆使用自定義和用戶定義聚合的功能
許多的行業數據在本地聚合操作中是基於all/subsets分組定制輸入的，例如SUM, AVG, 和MIN, 以及其它公司。實例可能進行一個傅立葉變換或者進行一個精確的預先計算的處理。用戶自定義聚合允許通過多線程的散開/散入(關聯執行) 操作，因而，通過多重處理器應該很好的被分離。◆高性能表值，用戶定義函數
在保存實例化之前從流動表值，用戶定義函數中通過支持局部結果的時候，許多運算法則不要求從外部數據源而來的涵蓋所有條目的完整列表。一些例子包括了 “獲得最新的股票價格”, “獲得最新的事件日志”, 和 “獲得隊列中第一個項目”。用戶定義函數支持流動的數據。數據是被查詢到的而不是在某一時間點獲得的，因此應該避免讀取大量結果並且插入到內存中。
它的實際能力超過Transact-SQL表值,用戶定義函數, 而Transact-SQL在它被調用時必須展示實例化所有數據。在這種情況下， 普通的部分請求查詢它絕對勝過傳統的用戶定義函數。
我們應該從一個開發和系統管理服務共同體的角度來理解這個羅列出好壞用途的列表
程序范例
開發者用Visual Studio編寫代碼。 這是用數據庫引擎 .Net Framework 設計API來編寫程序最適合的工具。使用其它工具來開發程序是有可能的，例如Express toolset甚至Windows 記事本,但是他們缺乏數據庫引擎的神奇功能， 整合了MSDN和Visual Source Safe, 以及其它團隊發展工具。另外，Visual Studio提供了一個具有多樣性的配置，測試，賀調試工具，通過它經驗豐富的開發者可以開發高終端程序。
圖 4
舉一個簡單的例子: 在開發者完成他們的解決方案之後，他們使用.Net Framework編譯器來編譯程序集(一個後綴為.dll 的文件存儲在目標文件服務器上)然後不是手動就是自動的再數據庫中配置二進制程序集。
在程序集assembly被加載進數據庫後，它就與原始的文件（以.dll為後綴的文件）獨立開來。 這意味著不用擔心外部對象依賴關系就可以對數據庫進行備份，移動甚至存儲操作。因為他們全部預先加載進數據庫中。注意原始源代碼必須仍然維護操作，而且所有改變都應該被記錄下來。
以下的建議是為了使開發者得到最大生產力：
◆開發者應該擁有一整套的專業工具
◆Visual Studio 2005 組系統和 MSDN
◆臨時數據庫引擎的SQL Server 2005 Express 。.Net Framework API users和一些測試和開發的限制窗體
◆為正規的數據庫 .Net Framework API 用戶提供的SQL Server 2005 開發者版本
◆為組訪問源代碼和釋放管理提供的Visual 源安全或者一個同等的源控制管理系統
◆開發者需要訪問類產品數據。
◆一個擁有合理的相關表大小繼承和模糊的靈敏型客戶數據的scaled-down版本的數據庫產品, 應該允許被訪問使它能夠被測試和更正原形。一個很重要的解釋是其它的工具，例如SQL Server 2005整合服務，可以被用來為你的產品數據庫創建一個豐富的開發者版本，你的產品數據庫可以包含隱式信任卡，名稱，地址，及社交安全數字。
◆訪問測試web服務來測試和其他系統的整合。
針對每個開發者的數據庫.Net Framework基礎結構有一些限制。它包含了當使用Visual Studio調試器來跟蹤代碼時的執行過程是CLR引擎的單一的線程，除了最後的報表，調試決不可能取代生產系統。
經驗豐富的程序員推薦使用SQL Server 2005開發者版本，因為它為程序員們提供了Management Studio，它的資源控制API是絕對完整的。這個版本也包含了SQL Server Profiler，這樣做是為了適應了SQL Server的需要。這個版本裡還包含了在腳本和自動控制方面大量的工具， 由於數據庫管理員和開發者的角色有重疊， 這樣做就可以使開發者在創建和調試數據庫對象例如SQLCMD時更加多產。想知道更多關於工具的信息，請登陸白皮書結束部分所列出的資源及網站鏈接。
