在SQL Server
的許多被大力推薦的特性裡面
有一項可能對那些使用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昂貴並且范圍廣泛
正確的工作選擇正確的工具
盡管擁有眾多選擇也不錯
From:http://tw.wingwit.com/Article/program/SQLServer/201311/22219.html
