有關SQL Server 2005 CLR

　　在SQL Server 2005的許多被大力推薦的特性裡面，有一項可能對那些使用SQLServer 工作的編程人員最實用的是Common Language Runtime，或者簡寫為CLR。CLR可以讓編程人員直接在SQL Server中建立預存程序、觸發器，使用者自訂函數，集合體和類型。CLR有很多的承諾，但是也有一些缺陷。

　　關於CLR的重要性有一些主要的原因。首先，隨著SQL Server 編程技術的成熟，代碼編寫人員陷入了SQL Server自身的一些限制之中，並且在很大程度上依賴外部的代碼來執行一些繁重的移植。T-SQL (交易處理SQL)在返回資料集方面很好，但是除了這個之外則表現不佳。CLR使得問題的解決有了可能，並且在SQL Server內部進行資料操作，而這些原本需要一個完全獨立的程式來實現的。.NET的作業碼和執行速度比SQL Server/T-SQL好得多;.NET中的同一位的代碼可以運行更快地運行許多次，當它是二進位的，而不是作為預存程序來構建時。

　　使用CLR的另一個巨大的好處就是安全。所有的代碼都在運行前檢測類型和安全許可權。例如，先前沒有被寫入的記憶體是不允許被問題中的代碼讀取的。CLR也很完善;.NET架構中的每樣東西都可以從預存程序、觸發器或者使用者函數進行訪問——除了處理類似使用者介面的類，它在SQL Server是無論如何不會有用的。

　　要防止CLR代碼胡亂運行，微軟為CLR代碼的調用建立了一個三層的安全模型:SAFE, EXTERNAL_ACCESS 和 UNSAFE。SAFE許可權集合在本質上與傳統的預存程序能夠做的事情一樣。在SQL Server之外不能對其進行任何修改。EXTERNAL_ACCESS允許通過.NET對註冊表和檔案系統進行訪問。UNSAFE正如其名。標記為UNSAFE的代碼不能做任何事情，並且它實際上是不應該在調試或者實驗環境之外使用的。大多數的編程人員應該永遠都不需要用到高於EXTERNAL_ACCESS層級的任何東西。(如果你需要在預存程序或者函數的環境中與檔案系統或者註冊表對話，這有可能意味著你需要重新考慮你嘗試的邏輯了。)

　　然而，CLR並不是適合一切。一方面，它可能適合那些不容易、需要進行編程，在T-SQL中實現的環境。許多簡單的操作可以在T-SQL以預存程序的方式完成，並且不需要擴充到外部進程。這意味著上下文交換和額外的事務開銷，這兩項中的任何一項開銷都能首先抹消你使用CLR獲得的速度提升。CLR最好用於替代擴充預存程序——例如，那些必須封閉在資料庫中，但是卻非常麻煩，無法用T-SQL從容完成，同時又不能輕鬆移動到商務邏輯末尾的事情。

　　另一個可能的缺點就是:正如SQL的領袖Rod Paddock在他的blog中指出的，如果你講商務邏輯中的某個元素移動到資料庫，那就可能會引起可測量性的問題。畢竟，SQL Server 更適合於按比例提高的單個大型主機器，而不是橫跨在幾個比較小的機器(通常是按照業務比例來的)上。這一點指出了有選擇的使用CLR有多重要。T-SQL簡潔、有效;CLR/.NET昂貴並且範圍廣泛。正確的工作選擇正確的工具，儘管擁有眾多選擇也不錯。