本文描述了數據庫應用程序開發人員和架構師如何利用 sql server 2005 中的 clr 集成功能。本文對基于 clr 的編程方式與 sql server 中支持的現有編程模型（如 transact-sql 和擴展存儲過程）進行了比較，并且強調了各自相對的優缺點。還提供了一組選擇合適的編程替代方法的高級指導，以及一些示例和代碼示例。

　　一、簡介

　　microsoft 通過宿主 microsoft .net framework 2.0 公共語言運行庫 (clr)，sql server 2005顯著地增強了數據庫編程模型的功能。它支持用任何 clr 語言（特別是 microsoft visual c# .net、microsoft visual basic .net 和 microsoft visual c++）編寫過程、觸發器和函數。同時，它還提供了擴展數據庫系統中的類型系統和聚合函數的功能，方法是允許應用程序創建它們自己的數據類型和聚合函數。

　　本白皮書從數據庫應用程序開發人員的角度描述了如何最有效地利用這項技術。它還將 clr 與 sql server 中支持的現有編程語言（即 transact-sql (t-sql) 和擴展存儲過程 (xp)）進行了比較。本白皮書不打算提供這些功能的基本參考資料，sql server 2005 beta 2 books online 對其進行了詳細介紹。

　　本白皮書的目標讀者包括數據庫應用程序開發人員、架構師和數據庫管理員。本白皮書假設讀者熟悉基于 .net framework 的編程和數據庫編程。

　　二、clr 集成概述

　　下面簡要概述了 clr 集成執行的 sql server 功能，以及 visual studio 2005 最終發布版本如何支持這些功能。

　　注冊和執行數據庫中的托管代碼包括以下步驟：

　　visual studio 2005 beta 1 支持在 sql server 2005 中開發、部署和調試托管代碼。有一種新的項目類型（稱為 sql server 項目），它允許開發人員在 sql server 中開發、部署和調試例程（函數、過程和觸發器）、類型和聚合。

　　構建和部署

　　sql server 項目提供了代碼模板，這使得開發人員能夠輕松地開始為基于 clr 的數據庫例程、類型和聚合編寫代碼。該項目還允許添加對數據庫中其他的程序集的引用。在構建項目時，可以將其編譯成一個程序集。部署此程序集可以將程序集的二進制文件上載到與該項目相關聯的 sql server 數據庫中。部署操作還自動創建在數據庫的程序集中定義的例程、類型和聚合，方法是使用在代碼中定義的自定義屬性（sqlprocedure、sqlfunction 和 sqltrigger 等等）。它還上載與該程序集相關聯的源代碼和 .pdb 文件（調試符號）。

　　調試

　　對于任何平臺來說，調試都是開發人員體驗的基本部分。sql server 2005 和 visual studio 2005 為數據庫編程人員提供了這些功能。調試 sql server 2005 對象的關鍵部分在于其易于安裝和使用。調試到運行 sql server 的計算機的連接在很大程度上同調試傳統操作系統中運行的進程的方式一樣。調試器的功能不會受到客戶端到服務器的連接類型的影響。這樣就可以調試表格數據流 (tds) 和 http 連接。而且，還可以跨語言進行無縫調試。因此，如果有一個調用 clr 存儲過程的 t-sql 存儲過程，調試會允許您從 t-sql 過程進入到 clr 過程。

　　三、clr 與 transact-sql

　　現在我們進入本文的關鍵部分：對 clr 集成和 sql server 中支持的現有編程語言進行比較。

　　transact-sql (t-sql) 是 sql server 支持的本機編程語言。和大多數 sql server 版本一樣，它包含數據處理功能和數據定義功能。數據處理功能一般可以分為兩類：查詢語言（由 select/insert/update/ delete 語句組成）和過程語言（while、賦值、觸發器、光標等）。一般來說，sql server 中的 clr 支持為過程語言提供了 t-sql 的替代方法。

　　即使在 sql server 中引入 clr 支持以前，數據庫應用程序應該盡可能多地使用查詢語言，這始終被認為是很重要的。數據庫應用程序應該利用面向集的查詢處理器，并且只在查詢語言無法表示邏輯時才轉向過程編程。對于 sql server 中的 clr 支持，這仍然是正確的。不應該使用 clr 來編寫可以用簡單的 select 語句表示的過程代碼。在 sql server 2005 中增加了許多重要的功能來提高t-sql 查詢語言的表達能力。

　　試圖使用 clr 功能的開發人員應該確保他們充分地利用查詢語言，包括 sql server 2005 中的擴展在內。對于在查詢語言中無法以聲明方式表示的邏輯，他們應該考慮將 clr 作為有效的替代辦法。

　　現在讓我們看一些方案，其中基于 clr 的編程能夠補充 t-sql 查詢語言的表達能力。通常，需要在查詢（可稱為函數）內嵌入過程邏輯。這允許許多方案，例如：

　　sql server 2000 引入了支持這些方案的 t-sql 函數（標量和表值）。有了 sql server 2005，就可以用 clr 語言更容易地編寫這樣的函數，并且會極大地提高它們的性能。之所以編寫這些函數非常容易，是因為事實上編寫 clr 代碼的開發人員可以利用 .net framework api中存在的大量有用函數和類。這個類/函數庫比 transact-sql 中支持的內置函數要豐富得多。此外，clr 編程語言提供了 t-sql 中所沒有的豐富構造（例如數組和列表等）。與 t-sql（它是一種解釋語言）相比，clr 編程語言之所以具有更好的性能，是因為托管代碼是已編譯的。對于涉及算術計算、字符串處理、條件邏輯等的操作，托管代碼的性能可能要優于 t-sql 一個數量級。

　　注：對于函數，幾乎沒有必要從函數中訪問數據庫。外部查詢已經從數據庫中檢索到數據值，并且將其作為參數傳遞給函數。這是 clr 的優勢，在計算性任務上比 t-sql 更勝一籌。

　　從 clr 中訪問數據

　　現在讓我們從編程模型和性能這兩個方面，看看如何用 clr 來編寫訪問數據庫的業務邏輯。

　　編程模型

　　使用 t-sql，只是在過程代碼內部嵌入查詢語言語句 (select/insert/update/ delete)。通過托管代碼，可以使用 sql server 托管提供程序來實現 microsoft ado.net 數據訪問 api（也稱為 in-proc ado.net）。使用這種方法，可以將查詢語言語句（select 和 dml 語句）作為動態字符串嵌入，并且將其作為參數傳遞給 ado.net api。與 t-sql 的靜態方法相比，過程代碼內嵌入的 sql 語句的基于動態 api 的特性是它們在編程模型上的主要區別。不利的是，in-proc ado.net 模型會產生比 t-sql 更冗長的代碼。此外，因為 sql 語句是動態字符串，所以在執行之前不在語法或語義上進行編譯和驗證。有利的是，帶有 ado.net 的數據庫編程模型與客戶端或中間層中使用的模型相似，因而更容易在各層之間移動代碼和利用現有的技術。

　　此外，在基于 t-sql 和基于 clr 的編程模型中使用的都是同一 sql 查詢語言，不同之處在于過程部分，注意到這一點是非常重要的。

　　性能

　　正如已經提到的，在談及過程代碼、計算等方面時，與 t-sql 相比，托管代碼在性能方面具有決定性的優勢。然而，對于數據訪問方面，t-sql 在性能方面通常會更好。因此，通用規則是用 clr 編寫計算和邏輯密集的代碼要比數據訪問密集的代碼好。不過這值得更詳細地考慮。

　　讓我們看看數據訪問編程中的一些典型的基元和模式，以及在這些情況下如何使用 ado.net 進行 t-sql 和托管編程。

　　將結果發送到客戶端

　　這包括將一組行發送到客戶端，而沒有在服務器中“消費”它們（即沒有在例程內導航行）。使用 t-sql，只需在 t-sql proc 中嵌入一個 select 語句就可以將 select 產生的行發送到客戶端。通過托管代碼，可以使用 sqlpipe 對象將結果發送到客戶端。t-sql 和 in-proc ado.net 平臺在這種情況下的作用是一樣的。

　　提交 sql 語句

　　這包括來自過程代碼的 sql 語句的執行往返。在這種情況下，t-sql 具有很大的優勢（比 in-proc ado.net 快兩倍多）。

　　此處需要重點注意的是，之所以在 clr 中出現性能降低，是因為增加了額外的代碼層，包括將來自托管代碼的 t-sql 語句提交給原生 sql 代碼。在將該語句提交給查詢處理器之后，基于語句源（t-sql 或 in-proc ado.net）的性能方面就沒有什么不同了。

　　注：典型的數據訪問密集的存儲過程可能涉及提交一系列的 sql 語句。如果 sql 語句簡單，并且不需要花費大量的時間執行，則來自托管代碼的調用開銷可能占用大部分執行時間，這樣的過程用 t-sql 編寫將執行得更好。

　　只進、只讀行導航

　　這包括以只進、只讀方式一次導航一個由 sql 語句產生的行。在 t-sql 中，這是通過只進、只讀光標實現的。在 clr 中，這是通過 sqldatareader 實現的。通常，每一條語句都涉及一些處理。如果忽略了與每行相關聯的處理，則導航行在 clr 中就比在 t-sql 光標中稍慢。然而，如果您關心為每行執行的處理，則 clr 會更有優勢，因為 clr 在這種處理上比 t-sql 做得好。

　　帶有更新的行導航

　　如果需要根據光標中的當前位置更新行，則沒有相關的性能比較，因為 in-proc ado.net 不支持此功能，而應該通過 t-sql 可更新光標來進行此操作。

　　注 在任何可能的情況下，最好使用 update 語句來批量更新行，只有在這樣的修改無法用單一的 update 語句進行表示時，才應使用基于光標導航的 update。

　　以下示例說明在特定情況下如何確定 t-sql 和 clr 將執行：

　　下面是一些簡單的指導原則，可以用來在 clr 和 t-sql 之間進行選擇：

　　后面的部分將更深入地討論在處理結果集時何時及如何適當地使用 t-sql 和 clr。

　　clr 與 xp

　　在 sql server 以前的版本中，擴展存儲過程 (xp) 為數據庫程序開發人員提供了唯一可用的機制來編寫服務器端邏輯，這要么難于表示，要么不可能用 t-sql 編寫。clr 集成提供了一種更健壯的替代方法來編寫這種存儲過程。此外，使用 clr 集成，過去以存儲過程形式編寫的邏輯通常可以更好地表示為表值函數，因為它們允許它們允許將該函數構造的結果放在 select 語句中進行查詢（通過將這些結果嵌入到 from 子句中）。

　　以下是使用 clr 過程或函數與 xp 相比的優勢：

　　正如上面所提到的，在數據訪問和發送結果集給客戶端方面，clr 過程比 xp 做得更好。對于不包括數據訪問和發送結果的代碼，比較 xp 和托管代碼的性能就是比較托管代碼和原生代碼的性能。一般來說，在這些情況下托管代碼比不上原生代碼的性能。而且，當在 sql server 內運行時，從托管代碼到原生代碼的事務處理過程有額外的開銷，因為在移動到原生代碼和從原生代碼移回時，sql server 需要對特定于線程的設置進行額外的登記-保留。因此，對于在托管代碼和原生代碼之間有頻繁的事務處理的情況，xp 大大地勝過在 sql server 內部運行的托管代碼。

　　對于大多數擴展過程，如果考慮數據訪問和結果發送的可伸縮性、可靠性和性能優勢，clr 過程提供了更好的替代方法。對于性能主要是由處理（數據訪問和結果發送之外的）和頻繁的托管-原生轉換決定的情況，應該權衡 clr 的可伸縮性和可靠性的優勢與 xp 的原始性能優勢。

　　四、代碼位置：數據庫與中間層

　　通過在數據庫中提供豐富的編程模型，clr 集成提供了將邏輯從其他層移動到數據庫層的選擇。然而，這顯然并不意味著所有或大部分邏輯應該移到數據庫中。

　　將邏輯移到數據庫層可以減少網絡中的數據流量，但是增加了服務器上寶貴的 cpu 資源的負荷。因此，在應用程序中做出代碼放置的決定之前，要慎重權衡。以下注意事項適用于將數據庫層作為首選的代碼位置：

　　注即使在引入 clr 支持之前，上面的注意事項也是有效的。數據庫層中的 clr 支持意味著編程語言的選擇沒有妨礙代碼位置的正確選擇。

　　示例：生產安排

　　生產安排是制造企業的常見任務。在高層次上，它包括制訂何時生產多少單位數量的產品的計劃，以便能夠滿足需求、最大程度的降低庫存成本，同時將生產成本降到最低。有幾個算法將需求預測、庫存成本和生產線安裝成本作為輸入，而將制造策略作為輸出。

　　假定將來的需求預測存儲在 sql server 表中，則此類算法的實現有以下特征：

　　在中間層實現這樣的算法是可行的，但是在數據庫外移動輸入集方面有性能損失。在 t-sql 中將其實現為存儲過程也是可行的，但是因為需要復雜的計算，性能損失就顯現出來了。性能特征將隨著實際的數據量和算法的復雜性的不同而不同。

　　為了驗證 clr 集成是否適合于這樣的情況，我們舉一個特定的生產安排算法的示例 － wagner-whitin 算法的動態編程實現。正如所預料的，clr 集成優于 t-sql。對于這種情況，使用托管代碼還有其他好處。這種算法的實現需要使用大量的一維和多維數組、數據結構，而這些在 t-sql 中是不可用的。總之，clr 集成的性能要優于 t-sql 實現幾個數量級。

　　假定以下簡單的數據庫架構跟蹤可以生產的產品列表。

　　下表存儲了每周每個產品的需求預測信息。

　　給定一組產品，它們的庫存和啟動成本以及未來需求預測，我們創建了接受如下輸入參數的存儲過程：1)制訂生產進度表的日期，2)按進度表生產所需要的周數。

　　存儲過程返回帶有下表中的架構的行集。

　　
將 c# 版本的代碼復制到下面的代碼中，以說明這種可以從 clr 集成中大大獲益的情況：

　　
五、處理常見數據庫編程任務和問題

　　前一節在高層次上對基于 clr 的編程與 t-sql、中間層和擴展存儲過程 (xp) 進行了比較。在這一節中，我們將考慮數據庫應用程序開發人員經常遇到的一些編程任務和模型，并且討論如何使用 clr（以及在一些情況下如何不使用）進行處理。

　　使用 framework 庫進行數據驗證

　　sql server 2005 中的 clr 集成允許用戶利用 .net framework 類庫提供的豐富功能來解決其數據庫編程問題。

　　常規表達式的使用可以很好地說明 clr 集成如何增強了驗證和過濾功能。在處理數據庫中存儲的文本數據方面，常規表達式提供的模式匹配功能比通過 t-sql 查詢語言中的 like 運算符可用的模式匹配功能多。考慮以下 c# 代碼，它只是 system.text.regularexpressions 命名空間中的 regex 類的一個簡單包裝：

　　假設 stringfunctions.regexmatch 和 stringfunctions.extractareacode 方法已經被注冊為帶有 returns null on null input 選項的數據庫中的用戶定義函數（這允許該函數在任何輸入都為 null 時返回 null，這樣在該函數內就沒有特殊的 null 處理代碼）：

　　現在，可以在使用上述代碼的表的列中定義約束，以驗證電子郵件地址和電話號碼，如下所示：

　　另外，請注意 areacode 列是使用 dbo.extractareacode 函數從 usphoneno 列中取出地區代碼而得到的列。然后，可以對 areacode 列建立索引，這樣便于在表格中根據特定地區代碼查找聯系人的查詢。

　　更一般地講，此示例演示了如何利用 .net framework 庫來增強帶有有用函數的 t-sql 內置函數庫，這些有用函數很難用 t-sql 表達。

　　產生結果集

　　需要從運行在服務器內的數據庫對象（如存儲過程或視圖）中產生結果集可能是最常見的數據庫編程任務之一。如果可以使用單個查詢（select 語句）來構建結果集，則這只需使用視圖或在線表值函數即可實現。然而，如果需要多個語句（過程邏輯）來構建結果集，則有兩個選擇：存儲過程和表值函數。雖然 sql server 2005 有表值函數，但是它們只能用 t-sql 進行編寫。在 sql server 2005 中，通過 clr 集成，還可以使用托管語言來編寫這樣的函數。在這一節中，我們將討論如何決定使用存儲過程還是使用表值函數，以及使用 t-sql 還是使用 clr。

　　從 t -sql 過程可以將相關的結果作為表值函數的返回值返回，或者通過存儲過程內曾經隱式存在的“調用者管道”返回。從存儲過程的任何位置（不管執行的嵌套程度如何）執行 select 語句都會把結果返回給調用者。更嚴格地講，實際上 select 語句并沒有進行變量賦值。而且，fetch、readtext、print 和 raiserror 語句也隱式地將結果返回給調用者。

　　請注意，“調用者”一直沒有正確地定義，它實際上取決于存儲過程的調用上下文。

　　如果從任何客戶端數據訪問 api（如 odbc、oledb 和 sqlclient）中調用存儲過程，則調用者是實際的 api，并且它提供的任何一種抽象都可以表示結果（如 hstmt、irowset 或 sqldatareaderand）。這意味著，通常，從存儲過程中產生的結果將始終返回到調用 api 中，而跳過堆棧中所有的 t-sql 框架，如以下示例中所示：

　　在執行過程 proc2 時，proc1 產生的結果將轉到 proc2 的調用者。proc2 中只有一種方法可以捕獲產生的結果，即通過使用 insert/exec 將其存儲到永久表、臨時表或表變量中，從而將結果流式處理到磁盤。

　　在使用 insert/exec的情況下，“調用者”是 insert 語句的目標表/視圖。

　　sql server 2005 clr 存儲過程引入了新的“調用者”類型。當通過托管框架中的 in-proc 提供程序執行查詢時，就可以通過 sqldatareader 對象使結果可用，并且可以在存儲過程中使用結果。

　　
下面的問題是托管存儲過程如何將結果返回給它的調用者而不是通過 sqldatareader 來使用它。這可以通過稱為 sqlpipe 的新類來實現。通過 sqlcontext 類的靜態方法可以使此類的實例對托管存儲過程可用。sqlpipe 有幾種方法可以將結果返回給存儲過程的調用者。這兩個類都是在 sqlaccess.dll 中定義的。

　　sqlpipe

　　在 sqlpipe 類中可以使用的方法中，最容易理解的就是 execute 方法，它將命令對象作為參數接受。這個方法主要執行命令，并且沒有使執行的結果可用于托管框架，而是將結果發送給存儲過程的調用者。發送結果的這種形式在語義上與將語句嵌入 t-sql 存儲過程內是一樣的。在本文前面描述的性能方面，sqlpipe.execute 與 t-sql 是等價的。

　　對于返回的數據是由執行的查詢直接產生的情況，sqlpipe.execute 可以很好地工作。然而，在某些情況下可能希望1）從數據庫中獲得結果，進行操作或者轉換，然后發送它們，或者 2）將結果發送回原地而不是本地 sql server 實例。

　　sqlpipe 提供了一組可以協同工作以使應用程序可以將任何結果返回給調用者的方法：sendresultsstart、sendresultsrow 和 sendresultsend。在很大程度上，這些 api 類似于對擴展存儲過程的開發人員可用的 srv_describe 和 srv_sendrow api。

　　sendresultsstart 將 sqldatarecord 作為參數接受，并且指示返回的新結果集的開頭。該 api 從記錄對象讀取元數據信息，并且將其發送給調用者。該方法有重載，以允許發送元數據以及記錄中的實際值。

　　隨后可以返回行，方法是對要發送的每行調用一次 sendresultsrowows。在發送完全部所需的行之后，需要調用 sendresultsend 來指示結果集的結尾。

　　例如，下面的 c# 代碼片段表示一個存儲過程，它讀取 xml 文檔（來自 msdn 的 really simple syndication [rss] 供給），使用 system.xml 類進行解析，并且以相關的形式返回信息。請注意，這些代碼應該創建為 external_access（或 unsafe）程序集，因為訪問 internet 所需的代碼訪問安全 (cas) 權限只有在這些權限集中才是可用的。

　　注：在 sendresultsstart 和 sendresultsend 調用之間，sqlpipe 被設置為繁忙狀態，調用除 sendresultsrow 之外的任何 send 方法都會導致錯誤發生。sqlpipe 處于繁忙狀態中時，sendingresults 屬性被設置為 true。

　　表值函數

　　clr 集成也啟用了對用托管語言編寫的表值函數 (tvf) 的支持。與 t-sql 相似，tvf 主要用于返回表結果。最顯著的不同在于，t-sql 表值函數臨時將結果存儲在工作表中，而 clr tvf 則能夠對產生的結果數據進行流式處理。這意味著結果在從函數返回之前不需要物化。

　　注 t-sql 還具有內聯 tvf 的概念，即不臨時存儲結果。內聯 tvf 在大部分語義上便于指定子查詢（可能帶有參數）。

　　托管 tvf 返回 isqlreader 接口，這是由 sqlclient 和 sqlserver (in-proc) 托管提供程序中的 sqldatareader 實現的一種只進光標抽象。查詢處理器調用此接口上的 read() 方法，以在每行返回 false 之前獲取它。

　　將上面的示例改為返回來自 rss 供給的信息，返回結果的代碼如下所示（不包括未實現的方法）：

　　使用來自此表值函數的結果的一種簡單查詢如下所示：

　　顯然可以用此數據的 tvf 形式來表示更豐富的查詢。假定函數 canonicalurl() 會返回規范的 url 版本。現在，可以使用規范的 url 很容易地返回來自 rss 供給的數據：

　　
請注意，在這個示例中，我們沒有利用 tvf 的流化功能，因為我們正在使用整個 rss 供給，在此之上建立導航器，然后在調用 read() 時循環訪問各個項目。然而，可以想象使用流式 api 來使用 web 資源的結果，并且使用 xmlreader 來循環訪問產生的 xml。需要重點注意的是，給出了 clr 表值函數和 t-sql 函數之間的執行模型的不同時，最主要的性能差異可能有利于 clr tvf，特別是在可能將結果數據流化的情況下。

　　使用哪一個？

　　決定將存儲過程與 sqlpipe （不管是 t-sql 中使用隱式管道還是在托管中使用顯式托管類）結合使用，還是使用表值函數，取決于以下幾個必須考慮的因素：

　　可組合性

　　有時可能需要重用或進一步處理 tvf 或存儲過程中產生的結果。從可組合性的角度來說，表值函數更靈活。tvf 的返回類型是相關的行集，可以用在允許此類構建的任何地方。特別是，它可以用在 select 語句的 from 子句中，因為這些產生的結果可以受益于子查詢中的 select、insert/select、派生的表和通用表表達式等的可組合性。

　　另一方面，從 t-sql 語言中，存儲過程可以組合成 insert / exec 組合的唯一部分，這使得可以將產生的結果存儲在永久或臨時表中。insert 操作表示數據的實際副本，它可能會影響性能。

　　如果需要組合和重用服務器中的結果，tvf 是更好的替代方法。如果產生的結果只需要回流到客戶端/中間層，任何一種方法都可以完成這項工作。

　　數據源

　　返回的數據源是在基于 t-sql 和基于 clr 的實現之間做出決定的另一個重要因素。可以通過使用 in-proc 提供程序讀取本地實例中的一些數據源產生結果，也可以從 sql server 之外的數據源產生結果。本文前面描述的基于 web 請求的結果構造的代碼片段便是后者的示例。另一個遠程數據源的示例是，使用 sqlclient 托管提供程序從遠程sql server 實例中檢索結果。對于這樣的外部源，基于 clr 的實現是更好的選擇，因為使用它可以很容易地實現訪問外部數據的邏輯。

　　現在讓我們考慮這種情況，使用 in-proc 提供程序基于在本地實例中執行的查詢生成結果。在使用 tvf 的情況下，默認的處理可能是返回由 in-proc 提供程序產生的 sqldatareader，或者用 isqlreader 的自定義實現包裝這樣的閱讀器，以便在讀取結果時對其進行轉換。在使用存儲過程的情況下，根據本地實例產生的結果必須執行查詢，循環訪問讀取行，對結果執行一些操作，然后通過管道將其發送回去。

　　然而，sql server 2005 不允許表值函數返回時請求還處于未決狀態。在函數體可以返回之前，必須全部執行任何通過 in-proc 提供程序執行的查詢并且完全使用結果。如果執行了返回語句，而 in-proc 提供程序中的 sqldatareader 操作還處于未決狀態，就會引發錯誤。這意味著對于從本地數據庫實例返回數據的大多數情況，無法通過 clr tvf 流化結果。如果因為其他因素（例如可組合性）需要將此編寫為 tvf，則使用 t-sql 編寫是唯一的選擇。另外，通過 sqlpipe 使用托管存儲過程是一個可能的選擇。

　　請注意，對于基于來自本地實例的數據從存儲過程中產生結果的情況，sendresultsxxx api 的使用只有在需要對結果進行修改或處理時才有意義。如果在未作修改的情況下將結果發送給調用者，則 sqlpipe.execute 是更好的執行解決方案。

　　副作用操作

　　一般來說，不允許用戶定義的函數（特別是表值函數）執行副作用操作。其中包括改變數據庫狀態的操作（如 dml 語句或事務處理操作）。在產生結果前后可能需要對系統狀態作一些修改。例如，業務組件可能需要設置 savepoint 事務，執行一些 update，并且通過管道返回結果；但是如果出現錯誤，則回滾到 savepoint。

　　如果不允許從 tvf 執行副作用操作，則只有存儲過程才能實現這樣的方案，并且必須通過 sqlpipe 返回結果。

　　請注意，當 sqlpipe 忙于發送結果時，尤其不允許通過 in-proc 提供程序執行副作用操作。只有在完成結果集之前或之后允許進行這些操作。

　　強類型化和返回的結果集的數量

　　從上面的代碼示例和與 t-sql 一致的角度來看，由存儲過程通過 sqlpipe 產生的結果的描述不同于 tvf。tvf 是強類型化的，并且作為注冊 (create function) 語句的一部分，它必須靜態地定義 tvf 產生的結果的列數和類型。

　　另一方面，存儲過程聲明并沒有聲明產生的結果 － 甚至是否返回結果。這看起來可能很方便，雖然它確實提供了更大的靈活性，但是在編寫執行存儲過程的應用程序時要更加細心，因為存儲過程可以動態地重定義產生的結果的形式。

　　因此，自然而然建議根據元數據來描述結果：如果結果的架構需要根據調用的不同而變化，則只有 sqlpipe 才能提供這種靈活性。

　　同樣地，通過存儲過程內的 sqlpipe 產生的結果的弱類型化不能將單個結果的架構擴展為可能返回可變數量的結果集。存儲過程可以自由地根據條件確定是否發送給定的行集和定義其形式。這樣的靈活性增加了使用這種可變的結果流的應用程序的復雜性開銷。

　　下表總結了如何在兩者之間做出決定的指導原則：

　　對于本節的大部分內容，通過 sqlpipe 發送結果是與過程緊密相關的。即使在 clr 觸發器主體中 sqlpipe 是可用的并且返回結果是可能的，也很不提倡這種做法，因為使用在目標對象中定義的觸發器發出數據處理語言 (dml) 或數據定義語言 (ddl) 語句可能會導致意外的結果。

　　將標量分解為行

　　經常需要在應用程序中傳送多值參數。例如，在定單處理系統中，可能需要編寫存儲過程來將定單插入到 orders 表中。存儲過程中的參數之一可能是定單中的行項目。在這種情況下，您會遇到 t-sql 限制，它不支持表值參數或缺乏集合數據類型（如數組）。解決這個問題的一種方法是，將集合編碼為一個標量值（如 nvarchar 或 xml），然后將其作為參數傳遞給存儲過程。在存儲過程內，可以使用表值函數來接受標量輸入，并將其轉換成一組行，然后將這些行插入到 lineitems 表中。

　　雖然可以用 t-sql 編寫表值函數，但是用 clr 實現它有兩個好處：

　　下面的代碼片段顯示了如何實現一個表值函數，它接受以‘;’分隔的一組值作為輸入字符串，并且以一組行（字符串中的每個值一行）的形式返回該字符串。請注意，mysqlreader 類的構造函數實現了大部分工作，它使用 system.string.split 方法將輸入字符串分解為數組。

　　假定 getstrings 方法注冊為具有相同名稱的 tvf。下面是存儲過程的代碼片段，它使用此 tvf 從定單中提取表形式的行項目。

　　
對數據進行自定義聚合

　　在許多情況下，您可能需要對數據進行聚合。這包括執行統計計算（如 avg、stddev 等等）。如果所需的聚合函數不是作為內置聚合函數直接支持的，sql server 2005 中有三種方法可以進行這樣的自定義聚合：

　　讓我們在一個稱為 product(int) 的簡單聚合函數的上下文中檢查這三種替代方法，該聚合函數計算一組給定值的乘積。

　　作為用戶定義的聚合函數實現的 product

　　下面是此函數的主干 c# 代碼示例。所有的積累邏輯都在 accumulate 函數中（為了簡單起見，其他函數顯示為 {...}）。

　　在定義類型、創建程序集和注冊到 sql server 之后，就可以通過以下方式使用 t-sql中的聚合函數：

　　作為使用 sqldatareader 的托管存儲過程實現的 product

　　可以創建存儲過程來執行查詢和循環訪問結果，以執行計算。這種循環訪問是通過使用 sqldatareader 類完成的。

　　可以使用 exec 語句來調用這一過程

　　作為使用光標的 t-sql 存儲過程實現的 product

　　可以創建 t-sql 存儲過程來執行查詢和通過使用 t-sql 光標循環訪問結果，以執行計算。

　　決定是使用 uda 還是使用其他某種解決方案來產生結果取決于幾個因素：

　　使用 uda 的第一種方法在這三個選擇中可能提供最好的性能。通常，如果沒有碰到上面所列的限制，就應該嘗試將聚合函數編寫為 uda。如果無法使用 uda 方法，則使用 sqlreader 的托管代碼方法可能比 t-sql 光標方法執行得更好。

　　可以用 uda 方法編寫的有用的聚合的示例還包括：找到每組中第 n 大（或第 n 小）值，找到每組中前 n 個最大值的平均值或總和，等等。

　　六 用戶定義的類型 (udt)

　　現在，我們來講 sql server 2005 中功能更強大但是經常被錯誤理解的一個功能。使用用戶定義的類型 (udt)，可以擴展數據庫的標量類型系統（不僅僅為系統類型定義您自己的別名，這在 sql server 以前的版本中一直可用）。定義 udt 就像用托管代碼編寫類，創建程序集，然后使用“create type”語句在 sql server 中注冊該類型一樣簡單。下面是實現 udt 的主干代碼：

　　何時創建 udt

　　sql server 2005 中的 udt 不是對象相關的擴展性機制。它們是擴展數據庫的標量類型系統的一種方法。標量類型系統包括 sqlserver 附帶的列類型（如 int、nvarchar 和 uniqueidentifier 等類型）。例如，使用 udt，可以定義您自己的、用于列定義的類型。如果您的類型確實是一個適合建模為列的原子值，請創建 udt。

　　如果需要定義您自己的標量類型，請使用 udt。這種類型的示例情況包括各種日歷中的自定義日期/時間數據類型和貨幣數據類型。使用 udt，可以創建單個對象來公開類型上可用的所有行為，并且封裝或隱藏該類型所存儲的基礎數據。需要訪問數據的每個人都必須使用 udt 的編程接口。如果能夠利用 .net framework 中現有的功能（如國際化或日歷功能），這實際上又是考慮將類型實現為 udt 的一個很好的理由。

　　何時不創建 udt

　　不要使用 udt 來對復雜的業務對象（如雇員、聯系人或客戶）進行建模。您將會陷入 udt 的所有列限制（如，8kb 大小限制、索引限制）和在更新 udt 值時更新整個值的不利方面。對于復雜類型，udt 不是合適的數據建模抽象；因此對于這種情況，最好使用中間層對象相關映射技術。

　　設計 udt 時需要考慮的因素

　　因為它們是列形式的，所以可以定義整個 udt 值的索引，并且創建參考完整性約束（如 udt 列的唯一性）。還可以在比較和排序方案中使用 udt。

　　比較 udt 值是通過比較類型的基礎二進制表示完成的。如果使用 format.native 作為持久性機制，則會按照同在該類型中定義的一樣的字段順序創建永久形式；因此，請確保這些字段是按照類型的正確順序排列的。

　　udt 上的每個操作（除了比較）都要求 udt 的值反序列化，接著進行方法調用。這種模式有與之相關的固定開銷。如果要將類型建模為 udt（相對于表中的列），則在訪問類型屬性（相對于表中的列）時應該考慮這種差別。如果類型上的行為非常復雜，則應該考慮使用 udt。如果類型沒有任何與之相關的行為，則應該考慮將數據存儲為表中的列。

　　如果發現需要實現相關函數的庫，則 udt 中的靜態方法是一種可以方便地創建這種庫的封裝機制。可以通過使用 :: 語法來調用t-sql 中的靜態方法，如下所示：

　　實際方案

　　客戶希望在 umalquracalendar 中存儲日期時間值，這與 sql server 日期時間數據類型使用的 gregorian 日歷不同。他們想讓這個日期類型具有相同的基本行為集，即字符串轉換、日期部分、日期算法和 getdate()。

　　下面是這一數據類型的代碼片段。它使用 umalquracalendar 2.0 版，這是 .net framework 中的新類型。

　　字符串轉換和創建新值：

　　
日期部分類似功能：

　　dateadd/datediff:

　　下面是一些處理 t-sql 中的類型的示例操作：

　　小結

　　本文介紹了使用 sql server 2005 中的 clr 集成功能的指導原則、具體使用情況和示例。數據庫應用程序開發人員和架構師應該結合集中討論 sql server 2005 中的其他功能區（如 transact-sql、xml 和 service broker）的指導原則的其他文章來閱讀本文。

　　將來，我們計劃在這一領域提供更多白皮書，講解 clr 集成的可管理性、監控和故障排除方面的指導原則。

　　版權

　　這是一個預備文檔，在此處描述的軟件的最終商業版本發布之前可能對該文檔進行補充性更改。本文檔中包含的信息代表 microsoft corporation 在發布時對所討論問題的最新觀點。由于 microsoft 必須適應不斷變化的市場情況，因此，這些信息并非 方面所作的承諾，microsoft 也不能保證出版日之后提供的任何信息都完全正確。

　　本白皮書僅供參考。microsoft 對本文檔中的有關信息不作任何明示或暗示的擔保。

　　用戶有責任遵從所有適用的版權法。除了版權法所賦予的權利以外，未經 microsoft corporation 明確書面許可，不得擅自將本文檔的任何部分進行復制、存儲在或輸入可檢索系統，或以任何形式或方式（電子、機械、影印、錄制或其他方式）進行傳播，或用作其他目的。

　　microsoft 對本文檔中的主題持有專利權、專利申請權、商標權、版權或其他相關的知識產權。microsoft 只提供在任何書面許可協議中明確規定的權利，而不授予您本文檔的上述專利權、商標權、版權或其他知識產權。

　　除非另有聲明，否則本文中提到的示例公司、組織、產品、域名、電子郵件地址、徽標、人物、地點和事件都是虛構的，與任何真實的公司、組織、產品、域名、電子郵件地址、徽標、人物、地點或事件無任何關聯，也不應該被推斷為有任何關聯。

　　© 2004 microsoft corporation. all rights reserved.

　　microsoft、visual c++ 和 visual c# 是 microsoft corporation 在美國和/或其他國家/地區的注冊商標或商標。

　　此處提到的真實的公司和產品名稱是其各自所有者的商標。