關於預存程序能否用在項目中的思考

想想在項目裡能不能用預存程序？

不能：因為項目要涉及到不同的資料庫，更多的是為了以後換庫方便。在代碼裡直接寫SQL語句進行查詢。發生換庫時，只要簡單的換一下連接字串就可以了。這叫以不變應萬變，怎麼講呢，代碼不變，資料庫愛怎麼變就怎麼變換庫可以靈活到什麼程度，即使公司打算把Oracle項目換成Access做單機版也沒有任何問題。

能：預存程序的執行速度要快得多，一方面它不需要在商務服務器和資料庫伺服器之間折返，更因為它有一次編譯，較投遞 SQL語句而言，效率更高。況且Oracle可以用Java,C 編寫更高效的預存程序，SQL Server 2005則可以使用 .net，毫無疑問，預存程序的速度比美名其曰的業務組件要快的多。

一般人喜歡折衷。行嘛，既然二者都有理，我在適當的場合選擇適當的技術，需要效率高的時候，我才用預存程序。

我喜歡一邊倒。既然預存程序效率高，為什麼不用預存程序？

為了實現一個很小的業務運算，需要把資料提過來，然後又投回去，需要把資料庫的資料類型轉換成程式語言的資料類型，做完這些無謂的工作之後，最後的效果卻是拋回到資料庫，只要想到這一點，我們為什麼不使用預存程序而採用這種低效的方案。

須知現在的問題背景和那個資料庫山頭林立的年代已經完全不同了。如果說資料庫也存在階段的話，那種能否支援預存程序都參差不齊的年代屬於石器時代。目前的資料庫，連MySQL都要支援預存程序了，也就是說，它們基本上都在同一條起跑線。因此，無須考慮萬一我寫了預存程序，而“升遷”的目標資料庫不支援預存程序的問題。

但是，各種資料庫的預存程序的編寫方法並不一致。如果從SQLServer轉移到Oracle，意味著幾乎所有的預存程序都要重寫。這是換庫說在新時代的新說辭。這個說法是有事實憑據的，換庫多麻煩，預存程序要全部重寫。

實際上這個問題很容易解決??代碼產生。做好一個預存程序的模板，將模板中的資料庫類型標識換成"Oracle"，重建一次便萬事大吉了。既然不需要手工重寫，這個說法自然也站不住腳。或者製做一種調和於主流資料庫預存程序語言的中繼語言也可以，一個簡單的編譯器將它轉換為特定於某個資料庫的語言。

使用預存程序除了效率高之外還有其他優勢：

a) 商務規則指令碼化。編寫預存程序的SQL語句是一種商務規則的指令碼，當商務規則發生變化時，無須對業務組件使用編譯和替換的高超魔法??須知越高超越危險。預存程序將這個問題簡單的化解。

b) 可以直接應用程式資料庫內建的許可權管理。如果不使用預存程序，一個商務規則能不能運行，需要在業務組件裡進行控制，因此業務組件中需要另起一套許可權控制架構，這個架構和資料庫本身的許可權控制是同構的，正所謂疊床架屋，多此一舉。而利用資料庫的許可權管理則從源頭把關，直接安全。

c) 語言純粹。和在 .net/java代碼中混雜資料庫操控的笨拙代碼相比，預存程序完全使用SQL語言，儘管各種資料庫的方言有異。提取資料，處理資料，儲存結果的工作用同一種語言融在一處，無疑屬於更好的編程風格。這個問題可以類比於 ASP->ASP.NET，從代碼混雜到各自純粹。.net3.0 意圖使用 DLink技術把 SQL 語言變成程式設計語言的一部分，想法是類似的。

但相較於各自純粹而言，那種在 VB裡直接寫 FROM SELECT WHERE的做法恐怕也不可取。雖然我完全支援 Class Employee 這種語言層級的 ORM。

d) 便於移植。和以前資料庫山頭林立的年代不同，現在我們更不放心的是平台。如果我們使用 .net 平台，意味著我們放棄了傳說中更堅強的Linux ?? mono 恐怕還靠不住。如果我們使用 java，雖然得到了跨平台的好處，但是只能做 bs，而在 Windows平台又失去了 .net 所具備的高速度??後者是致命的。另外，如果客戶需要一個對配置要求不高反應又不遲鈍的 cs 程式，也許用 Delphi 更能符合使用者的願望。我們通常要在 win32/.net/java 平台之間做出選擇。而這種選擇沒有回頭路可走。如果我們把資料庫作業碼放在資料訪問層，把商務規則代碼放在業務層，一切都特定於某種平台了。相反，如果使用預存程序，商務規則部署於資料庫中，資料訪問層和業務層都只剩下一個殼，代碼大為簡化，使用任何平台的語言來改寫都可以快速完工。想想看，一周的時間就可以在一個新平台寫完前端，何樂而不為呢。

e) 方便的使用資料庫的事務機制。在程式語言中控制事務，無論哪個平台都有隔靴搔癢之感，而在純粹的SQL語言則顯得心應手，渾然一體。

就我理解，像便於換庫這種理由，從曆史原因來考察，是軟體開發傷口上的痛。這個問題一直到ODBC等等方案風行之後才得到解除。以前特定於某種類型的資料庫的程式，升遷所花費的代價是非常昂貴的。這次大動蕩給一代人投下了心理陰影，提到特定於某種資料庫時，便產生一朝被蛇咬，十年怕井繩的恐懼心理。

類似的事情還有函數嵌套函數。結構化程式設計中，一個關鍵性的觀念就是功能獨立，其程式功能被劃分為多個獨立的功能函數。但有些功能是受雇於另外的子功能的，並非第一級子功能。例如，通常一個遞迴會寫成兩塊，一塊發起遞迴，一塊遞迴，在類似無嵌套函數的語言中，發起遞迴會變成一個函數，遞迴過程又作為一個函數，這兩個函數地位平行。而在支援嵌套函數的語言中，遞迴過程可以實現為一個子函數，嵌入進發起函數。但是現在的語言多不支援嵌套，因為人們畏懼結構化，即使本不相左的交集。唯最近微軟披露的 .net 3.0 架構計劃引入該機制，也許是Anders很懷念Pascal，當然，更大的可能是微軟也意識到了這個問題。