在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 具有擴展性和包容性。正確的工作是采用正確的工具，雖然擁有很多的選擇是多麼好的一件事情。
