然而，在SQL Server 2005中，我們可以用.NET家族的語言——主要是VB.NET和C#來編寫存儲過程（以及方法、觸發器和其它組件）。讓我們來熟悉一下關於編寫存儲過程新方法的5個常見問題。它們是非常值得我們探討的。
1、為什麼我們必須使用CLR模式來編寫存儲過程呢？ 主要原因是速度。SQL CLR在很多方式下都運行較快：比如字符串處理，它比T-SQL運行快很多，並且對於錯誤的處理能力也更加強大。同時，由於CLR所提供的來執行這些事務的框架都更為完善，因此任何需要與數據庫之外資源進行事務交互的存儲過程——比如，文件系統或者Web服務——CLR SP都是表現最好的。
2、CLR最適合編寫哪些類型的存儲過程？ 一般來說，在數據上執行繁重計算而不是僅僅是查詢數據的SP最適合用CLR。如果一個CLR SP只是封裝一個復雜的SELECT語句，那麼我們將無法看到顯著的性能增益，因為每次運行SP時，都必須驗證CLR中的SQL語句。事實上，它比僅將SELECT語句作為T-SQL SP處理表現還要差。
一個經典的好方法是：如果需要執行的SQL的行數很多，那麼可以將SQL封裝在一個常規的SP上。如果想要在一個大的數據集上運行CLR風格的處理，那麼我們可以在CLR SP內部調用一個常規的SP來獲取這個大的數據集。這樣，常規的SP會被預編譯，性能也會更好，同時數據轉換性能也會有所提高。
注意：這種情況是假定我們需要在數據層上進行復雜的數據處理，而不是在顯示層上。事實上我們在編寫代碼之前就需要考慮這些問題。
3、是否應該把現有的存儲過程轉換為CLR模式？ 簡單而言，“要有好處才去做”。在這種情況下，可以為指定的存儲過程創建一個同等的CLR實現的版本，然後使用實際數據對兩種SP進行測試。除非我們可以確定新的存儲過程：（a）按照預計的方式運行，（b）對性能有實際的提升，否則應該繼續使用老的存儲過程。其實CLR跟其它的存儲過程一樣，沒什麼奇特的。
4、在沒有開發IDE的情況下，可以創建CLR（Common Language Runtime）存儲過程嗎？ 當然，我們可以通過C#編譯手動實現這類開發。然而，使用Visual Studio或者類似的IDE可以更簡單，特別是當我們在整個企業范圍內轉換或實現大量SP時。
5、轉換有多難？ 很明顯，我們必須具備其中一種支持語言的知識，如VB.NET或者C#。事實上，SQL命令是“封裝”在CLR代碼中的，因此，只要我們知道如何使用它，那麼在CLR重新實現現有的T-SQL是不難的。比較有難度的是如何使用這種語言來優化我們正在做的工作，這個問題就不是幾個要點就可以歸納的。
