1. 首頁
  2. 問答
  3. SQL SERVER CLR的優勢

SQL SERVER CLR的優勢

2009-01-13 49 views
12

SQLServer CLR比T-SQL有什麼優勢？使用.NET語法比T-SQL更容易嗎？我看到你可以定義用戶類型，但我不清楚爲什麼這樣更好。例如，你可以定義一個電子郵件類型，它會有一個前綴屬性和一個域屬性。然後您可以搜索域或前綴或兩者。但是，我沒有看到與添加一個稱爲前綴和一個稱爲域的列幾個列並分別搜索它們的方式有什麼不同。也許有人有現實世界的原因，爲什麼這更好。SQL SERVER CLR的優勢

來源

2009-01-13 Anthony Potts

+0

CLR使SSISDB部署，通過少RDP帳戶，文件系統管理和少權的要求，裏面的維護計劃備份的繼承，通過TDE全包加密從而大大提高了執行時間的評價，成功/失敗/ ETA日誌，安全，更不用說通過SSISDB的環境部分進行SSIS包部署和維護，以及SSIS中需要CLR的許多C＃函數缺乏。如果您計劃運行正確的SSIS部署或C＃，則在創建SSISDB時需要啓用CLR。 – 2016-01-01 01:45:46

回答

17

我舉一個很好的例子：CLR有一個內置的RegEx對象，這在SQL Server中非常缺乏。現在編寫函數來執行基於正則表達式的驗證約束/修復是微不足道的。

來源

2009-01-13 17:17:39

+0

如果你知道一個例子，我會喜歡這樣一個例子的鏈接。 – 2009-01-13 17:19:32

+2

http://weblogs.sqlteam.com/jeffs/archive/2007/04/27/SQL-2005-Regular-Expression-Replace.aspx – 2009-01-13 17:21:40

8

不同的目的。 CLR存儲過程對於編寫高度程序化代碼或使用不能從T-SQL訪問的系統設施將會有所幫助。儘管沒有固有的理由不能寫應用程序，但通常不會將CLR sprocs視爲一種用於編寫應用程序sprocs的不同語言。通常，CLR sproc的大多數用途都是爲了系統目的而不是應用程序組件，儘管這並不是一條堅強而快速的規則。

CLR集成層的確提供了一些不能從T-SQL存儲過程直接獲得的功能，例如自定義聚合函數。它還提供對.Net庫的訪問，這對於訪問T-SQL無法支持的功能可能很有用。

T-SQL做傳統的數據庫的東西，並與查詢優化器集成，所以它仍然是最適合面向集合的數據庫代碼。爲CLR sprocs提供了API鉤子以向查詢優化器提供信息，但這增加了一些複雜性。

也可以使用CLR集成來定義可供T-SQL代碼訪問的函數。在某些情況下，這些可能比T-SQL函數更快，更有效。 Wrox press book on CLR integration在一定程度上對此進行了討論。

來源

2009-01-13 17:12:16 ConcernedOfTunbridgeWells

6

你也可以例如從SQLCLR方法調用外部web服務 - 不完全可能在T-SQL :-)

馬克

來源

2009-01-15 17:19:40

2

SQLCLR /內SQL Server CLR集成僅僅是另一種工具來幫助解決某些（不是全部）問題。有幾件事比它在純T-SQL中可以做得更好，並且有些事情只能通過SQLCLR完成。我爲SQL Server Central寫了一篇文章，Stairway to SQLCLR Level 1: What is SQLCLR?（需要免費註冊才能閱讀那裏的文章），解決了這個問題。基本要點有（詳見鏈接的文章）：

  • 流表值函數（sTVF）
  • 動態SQL（函數內）對外部資源的
  • 更好的訪問/替換xp_cmdshell的
    • 傳遞數據更容易
    • 獲取結果集的多個列更容易
    • 沒有外部依賴關係（例如7zip。通過模擬
      • EXE）
    • 更好的安全性
  • 能夠多線程
  • 錯誤處理（函數內）
  • 自定義聚集
  • 自定義類型
  • 修改國家（函數內部和外部OPENQUERY/OPENROWSET）
  • 執行存儲過程（只讀;一個函數內並且沒有OPENQUERY/OPENROWSET）
  • 性能（注：這是在所有情況下不意義，但肯定是在某些情況下，根據操作的類型和複雜性）
  • 可以捕獲輸出（即什麼被髮送到在SSMS郵件選項卡）（例如PRINT和RAISERROR與嚴重性 = 0〜10） - I忘記提到這一個文章;-)英寸

另一個要考慮的是，有時是有益的是能夠在應用程序和數據庫之間共享代碼，以便DB具有洞察一定的業務邏輯，而不必構建自定義，僅供內部使用的屏幕只是訪問該應用程序代碼。例如，我曾參與過一個系統，該系統從客戶導入數據文件，並使用大多數字段的自定義散列並將該值保存到數據庫中的行中。這允許在再次導入數據時輕鬆地跳過行，因爲應用程序會對輸入文件中的值進行散列並與存儲在行中的散列值進行比較。如果它們相同，那麼我們立即就知道沒有任何字段發生了變化，所以我們進入下一行，這是一個簡單的INT比較。但是，執行哈希的算法僅適用於應用程序代碼，因此無論是調試客戶案例還是通過標記具有至少一個包含更改字段的行（從我們的應用程序發出更改）來查找將某些處理卸載到後端服務的方法而不是在新的導入文件中尋找更改），我無能爲力。這對於在DB中擁有相當簡單的業務邏輯來說是一個很好的機會，即使不是用於正常處理;在數據庫中具有相當於編碼值的數據而無法理解其含義使解決問題變得非常困難。

如果您有興趣看到其中一些功能無需編寫任何代碼，則免費版SQL#（我是其作者）具有RegEx函數，自定義聚合（UDA），自定義類型（UDT），等

來源

2014-07-14 20:38:51

相關問題

 相關問題