最近有個爭論，就是視圖到底怎麼寫才更有可擴展性？
有兩種寫法：
1，select 。。。，GetName（CD） name from AA；語句中GetName是一個帶返回值的存儲過程
2，select 。。。，BB.name name from AA join BB。。。；
其中一方認爲第一種寫法更具可擴展性？！
我們來分析下。
首先排除掉物理部署上的可擴展性問題，也就是說到底是採取寫在應用服務層上還是寫在數據庫裏？當然，前者比後者可能稍微麻煩點（這要看部署策略和維護策略）；那麼，剩下的就是代碼編寫和維護層面上的可擴展性問題；
首先，我們判斷業務邏輯的更改會不會造成可擴展性問題？
一種情況，是數據結構的改變而且涉及業務邏輯，比如需要增加一個字段（不涉及業務邏輯的例子：增加個備註字段，僅僅是輸入輸出，框架從技術層面也能自動解決這樣的升級而無須編寫業務代碼），這個字段還要經過業務邏輯代碼的處理，那麼，必然要改變各個業務邏輯層之間的接口，爲什麼？業務邏輯層之間不管採取什麼形式，都是調用和被調用的關係，參數的發送和接受都需要對傳遞的信息進行打包和解析，對於業務代碼來說，一定要清楚參數的含義，也就是顯式的處理代碼。那麼這種改變造成的代碼修改是不可避免的，儘管框架可以在層與層之間做些傳遞上的自動化處理（比如Packer和CSLA的做法）。對於前面的例子來說，就是SQL語句中增加了一個字段，視圖要改寫，視圖的調用方也得改寫。
另一種情況，是業務邏輯的處理方法發生了改變，對於前面的例子來說，就是GetName裏面的處理方法發生了改變。那麼，只要參數定義（例子中是別名name）不變，對於調用方來說，確實沒任何影響（至於調用方是否要對新的name值進行新的方法處理，那是另外回事，不影響對此SQL可擴展性的分析），也就是說，在接口（本例是視圖名、字段名、字段類型）不變的情況下，可擴展性問題被侷限在了一定範圍內。
既然我們把接口定義好了，可擴展性問題就僅僅是一個SQL內部的事情，這就簡單多了。
試問，一個存儲過程與一個關聯表SQL之間，其編寫難度、複雜度、代碼量、維護量、維護難度，哪個更大？
在我看來，區別僅在於後一種方法把業務邏輯暴露在了VIEW裏面。
可擴展性是蠻重要的，但是對於一個系統來說，不僅僅是這一方面要考慮的問題，它是權衡利弊下的產物，恩，效率有時候更加重要，因爲這是用戶最切身體會的方面。
題外話：是否採用存儲過程，更多的應該從可重用性來考慮。
