在SQL Server 2005的眾多被高度評價的特性中，有一個最適合那些對SQL Server編程的人員的就是通用語言運行時，縮寫為CLR(Common Language Runtime)。CLR允許編程人員直接在SQL Server 中創建存儲過程，觸發器，用戶定義函數，集合和類型。CLR有很多的承諾，但是它也具有一些缺陷。

　　CLR的重要性有幾個比較大的原因。首先，由于SQL Server編程已經成熟了，編碼器運行在SQL Server 自身可能的限制之中，并且很大程度上依賴于外部代碼來執行一些繁重的操作。T-SQL (Transact-SQL)在返回數據集合方面非常好，但是在其他方面就不是很好了。CLR使得解決問題和縮減SQL Server內部的數據復制成為可能，通過在SQL Server中需要完全地分離程序來努力實現。.NET操縱代碼以及執行速度方面比SQL Server和T-SQL 強得多；.NET中同樣位置的代碼由于是二進制，因此其運行多次仍然比構建為存儲過程快上許多。

　　使用CLR的另一個巨大的好處就是：安全。所有的代碼都是在運行之前檢測類型和許可安全的。例如，先前沒有被寫入的內存是不會被請求中的代碼訪問的。CLR還非常的完善；.NET框架中的素有的東西都可以在存儲過程、觸發器或者用戶函數中進行訪問——除了處理類似用戶界面的類，這些類在SQL Server中沒有用處。

　　為了避免CLR的瘋狂運行，微軟創建了一個三層的安全模型，規定了CLR代碼是如何調用的：安全、外部訪問和不安全(SAFE, EXTERNAL_ACCESS and UNSAFE)。安全權限設置與傳統的可以執行的存儲過程一樣重要。它不可以被SQL Server自身之外的任何東西修改。外部訪問允許通過.NET來訪問注冊表和文件系統。不安全的命名很恰當。被標記為不安全的代碼不能做任何事情，并且他們實際上在調試或者試驗環境之外無法使用。大多數的編程人員都不需要使用高于外部訪問的東西。(如果你需要在存儲過程或者函數的環境內訪問文件系統或者注冊表，那么很有可能標記著你需要重新考慮你正在做的事情的邏輯了。)

　　然而，CLR并不適合所有的東西。有一件事，它可能最適合那些不輕松、需要編程的、在T-SQL 中實現的環境。許多簡單的操作可以作為T-SQL中的存儲過程完成，并不需要做成外部處理。這意味著上下文替換和額外的事務負擔，這兩項中的每一項都會抵消你使用CLR帶來的最主要的速度的提升。CLR用于替換擴展存儲過程是最好的——例如，那些與數據庫關系密切，但是T-SQL 處理起來過于繁瑣的，并且很難輕松地移動到事物的業務邏輯端的。

　　還有一個可能的不利是:正如SQL 的領袖Rod Paddock 在他的blog里面指出的，如果你將業務邏輯的某個部分移動到更接近數據庫，那么有可能引起可測量性的問題。不管怎么說，SQL Server都更適合按比例擴大地放在單個的大型機上，而不是分布在多個較小的機器上(這通常是業務邏輯的測量方式S)。以上指出了有選擇地使用CLR是多么的重要。T-SQL 非常緊湊并且有效率；CLR/.NET 具有擴展性和包容性。正確的工作是采用正確的工具，雖然擁有很多的選擇是多么好的一件事情。

關鍵字：SQL Server 2005、CLR、觸發器、數據集合

【 頂部 】 【 關閉 】