在應用程序開發中可以通過函數來提高系統的性能與代碼的重復利用在SQL Server數據庫中也可以通過自定義函數來提高服務器的性能用戶自定義函數可以從外部接受必要的參數並在內部執行一些復雜的操作最後返回正確的結果
在數據庫開發中筆者強烈建議數據庫管理員要多用用函數只要能夠通過函數來實現的功能那麼就要用函數或許大家還不明白其中的原因沒有關系現把這個原則刻在心中然後筆者再跟大家解釋其中的奧妙
一利用函數來實現業務邏輯的優勢
函數的執行速度比普通的SQL代碼要快
在同等條件下實現同樣功能的SQL代碼與把SQL代碼定義成函數後者的執行性能要比前者高許多這主要是因為在數據庫中用戶自定義函數通過緩存計劃並在重執行時重用它來降低SQL代碼的編譯開銷如現在在數據庫中需要實現一個功能要返回企業在職員工每天遲到或者曠工的人員信息這個功能即可以每天通過一個SQL代碼來實現也可以把實現這個查詢的SQL代碼封裝成一個函數然後應用程序通過調用這個函數來實現這個需求如果通過SQL代碼來實現的話每天查詢一次數據庫都需要重新編譯並優化這條SQL語句而如果通過函數來調用的話則不需要重新解析和重新優化因為其執行計劃只要運行過一次就會在數據緩存中保存下來下次需要調用這個函數的話則直接調用緩存中執行計劃即可可見通過函數來實現某些常用的功能可以避免重復的解析與優化縮短執行時間提高數據庫性能
模塊化設計提高數據庫與應用程序開發性能
如上面這個例子企業剛開始的時候可能需要查詢遲到與曠工人員的編號姓名職位事由等信息但是後來用戶的需求發生了改變他們希望在這些信息的基礎上還能夠帶出當月累計遲到或者曠工的次數是否有正當手續等信息如果在數據庫與應用程序設計開發的時候是通過SQL代碼來實現這個功能的那麼此時筆者非常不幸的告訴大家要實現這個需求的話必須修改源程序中嵌入的SQL代碼這是一件非常麻煩的工作但是如果通過函數來實現的話則應用程序的源代碼基本上不需要更改而只需要在數據庫中更改這個函數的代碼這筆更改應用程序代碼要簡單的多時間也可以短許多
另外可能不僅一個地方需要用到這個SQL代碼在日常的查詢中在員工的績效考核系統中在工資核算系統中都需要這些內容如果用普通的SQL代碼來實現的話則在各個作業中都需要重復的書寫這些代碼顯然這個工作量非常的大最要命的是若以後用戶需求更改了的話需要同時修改多個地方的代碼顯然通過SQL代碼來實現某些需求的話代碼的重復利用程度不高這會影響數據庫的開發效率而通過函數來實現的話又有另一番新天地因為只需要創建一次函數並將其存儲在數據庫中那麼應用程序中就可以進行多次重復調用即使需求有改變的話只需要更改函數那麼其他各個作業的功能也會相應的更改
可見利用函數來實現功能不僅可以提高數據庫運行性能而且還可以提高數據庫與應用程序的開發效率
減少網絡流量提高數據庫運行性能
如果利用函數來實現某些功能的話則還可以明顯的減少網絡流量如上面這個需要要統計員工當月的遲到早退曠工次數如果通過SQL代碼來實現的話則需要先把員工當月每次遲到早退曠工的記錄返回到應用程序中然後再在應用程序中進行相關的統計但是如果通過函數來實現這個功能的話則處理方式就不一樣了利用函數來實現的話是在數據庫中統計好相關的結果如員工遲到的次數等等然後直接把這個結果返回給應用程序也就是說用戶最終需要的是一個統計結果而通過SQL代碼來實現的時候數據庫需要把員工遲到曠工等違紀信息的明細返回給應用程序而通過函數來實現的話則只是把最後的統計結果返回給應用程序顯然利用函數來實現其網絡傳輸的數據量要少的多這對於網絡帶寬受到限制的企業來說可以通過這種方式輕而易舉的縮短用戶的等待時間如果相關的記錄比較多或者用戶需要通過互聯網遠程訪問數據庫的時候這個效果特別明顯
二TransactSQL 函數與CLR 函數該用哪一種?
在SQL數據庫中不僅可以利用數據庫自帶的TransactSQL語言來編寫函數而且還可以使用Microsoft NET Framework 編程語言來編寫函數這在很大程度上提高了函數能夠實現的功能不過兩種語言在不同的情況下使用對於數據庫的性能的影響是不同的為此數據庫設計與開發人員必須了解這兩種語言的差異並在合適的情況下選擇合適的語言這有利於提高數據庫的性能在SQLServer數據庫中把利用Microsoft NET Framework 編程語言來實現的函數叫做CLR函數如CRL表量值函數用來返回單個結果的值如字符串數字等等那麼到底還如何進行選擇呢?筆者的如下幾個建議或許能夠幫助大家
第一個建議客戶端運行OR服務器運行?
以前在數據庫部署的時候由於客戶端配置的問題往往把所有的應用都放在服務器上實現如此的話只要提高服務器的配置即可但是隨著數據庫應用越來越復雜把所有的擔子都壓在數據庫服務器上已經讓數據庫服務器超負荷運行了隨著客戶端硬件配置的提高為此把一些運行時間比較長的作業放到客戶端來運行未嘗不是分攤服務器壓力的一種好方法如果數據庫設計與開發人員有這種想法的話那麼在選擇使用TransactSQL 函數還是CLR 函數的問題上就有了方向TransactSQL 函數與CLR 函數都可以在服務器上運行在服務器上運行函數的話可以將代碼與數據靠近在一起以減少不必要的網絡流量但是就如同上面所說的有時會數據庫設計人員出於整體性能的考慮不得不把一些運行時間比較長或者硬件資源耗用量比較大的作業放在客戶端上執行但是到目前為止TransactSQL 函數只能夠在服務器端執行CLR 函數的話不僅可以在服務器端運行而且還可以在客戶端上執行所以如果要把某個復雜的作業放在客戶端上運行而這個作業又需要調用某個函數的話那麼在這種情況下就需要采用CLR 函數
第二個建議業務邏輯的復雜性?
利用函數來實現的功能即可以是才十幾行代碼的作業也可以是包含幾百條業務邏輯的復雜功能在編寫函數的時候到底是采用TransactSQL 函數還是CLR 函數還需要看看其業務邏輯的復雜性因為TransactSQL代碼雖然也可以實現一些復雜的功能但是其畢竟不是屬於專業的開發語言當業務邏輯比較復雜的時候TransactSQL代碼開發和執行的時候效率並不是很好如現在要給用戶利用隨機數生成密碼在這個功能上利用TransactSQL代碼也可以實現但是其代碼會很長而利用CLR函數來實現的話則只需要簡單的幾行可見這個代碼的編寫量上就有很多的差別代碼量一增加那麼後續維護的工作量也就越大
為此為了提高函數的開發效率對於業務邏輯比較復雜並且可能會占用服務器比較多的CPU或者內存資源的函數最好采用CLR函數來實現這不僅可以簡化函數的開發而且在有需要的時候還可以把這個函數放在客戶端上去職執行一舉多得故在判斷到底采用哪種函數為好的話還需要考慮其業務邏輯的復雜性與硬件資源的耗用情況
總的來說在大部分情況下TransactSQL 函數與CLR 函數是通用的但是為了取得更好的性能可以根據以上的幾個建立來判斷到底利用哪種類型的函數另外如果采用擴展存儲過程的話最好也是采用CLR函數因為擴展存儲過程與CLR函數的兼容性比較好但是CLR函數是利用C#等編程語言開發的對於一些數據庫管理員來說可能有一定的難度這也可以說明未來的數據庫開發人員往往需要多掌握幾門語言才能夠勝任光靠SQL語言往往並能夠完成數據庫的全部設計與開發工作因為業務需求對數據庫性能方面的要求越來越高多門語言的結合使用有利於數據庫開發者設計性能更高的數據庫應用系統從而給用戶更快的享受提高用戶滿意度
From:http://tw.wingwit.com/Article/program/SQL/201311/16388.html
