為什麼要用儲存過程？ 

幾個去 IBM 面試的兄弟回來抱怨：去了好幾個不同的 IBM 專案組，幾乎每個面試官問到資料庫的時候都要問用沒用過儲存過程，煩人不？大家去面的程式設計師，又不是 DBA，以前的專案都沒有用到儲存，不照樣執行的好好的？

儲存過程真的那麼重要嗎，它到底有什麼好處呢？

筆者認為，儲存過程說白了就是一堆 SQL 的合併。中間加了點邏輯控制。

但是儲存過程處理比較複雜的業務時比較實用。
比如說，一個複雜的資料操作。如果你在前臺處理的話。可能會涉及到多次資料庫連線。但如果你用儲存過程的話。就只有一次。從響應時間上來說有優勢。
也就是說儲存過程可以給我們帶來執行效率提高的好處。
另外，程式容易出現 BUG 不穩定，而儲存過程，只要資料庫不出現問題，基本上是不會出現什麼問題的。也就是說從安全上講，使用了儲存過程的系統更加穩定。

資料量小的，或者和錢沒關係的專案不用儲存過程也可以正常運作。MySQL 的儲存過程還有待實際測試。如果是正式專案，建議你用 sql server 或 oracle 的儲存過程。資料與資料之間打交道的話，過程會比程式來的快的多。面試官問有沒有用儲存，實際上就是想知道前來面試的程式設計師到底做過資料量大的專案沒。如果是培訓出來的，或者小專案小公司出來的，對儲存肯定接觸的少了。

所以，要想進大公司，沒有豐富儲存過程經驗，是不行的。

那麼什麼時候才可以用儲存？對於資料量不是很大以及業務處理不是很複雜的小專案就無需要了麼？
錯。儲存過程不僅僅適用於大型專案，對於中小型專案，使用儲存過程也是非常有必要的。其威力和優勢主要體現在：
  1.儲存過程只在創造時進行編譯，以後每次執行儲存過程都不需再重新編譯，而一般 SQL 語句每執行一次就編譯一次,所以使用儲存過程可提高資料庫執行速度。
  2.當對資料庫進行復雜操作時(如對多個表進行 Update,Insert,Query,Delete 時），可將此複雜操作用儲存過程封裝起來與資料庫提供的事務處理結合一起使用。這些操作，如果用程式來完成，就變成了一條條的 SQL 語句，可能要多次連線資料庫。而換成儲存，只需要連線一次資料庫就可以了。
  3.儲存過程可以重複使用,可減少資料庫開發人員的工作量。
  4.安全性高,可設定只有某此使用者才具有對指定儲存過程的使用權。

儲存過程的使用，好像一直是一個爭論。     
  我不傾向於儘可能使用儲存過程，是這麼認為的：     
  1.   執行速度：   大多數高階的資料庫系統都有statement   cache的，所以編譯sql的花費沒什麼影響。但是執行儲存過程要比直接執行sql花費更多（檢查許可權等），所以對於很簡單的sql，儲存過程沒有什麼優勢。     
  2.   網路負荷：如果在儲存過程中沒有多次資料互動，那麼實際上網路傳輸量和直接sql是一樣的。     
  3.   團隊開發：很遺憾，比起成熟的IDE，沒有什麼很好儲存過程的IDE工具來支援，也就是說，這些必須手工完成。     
  4.   安全機制：對於傳統的C/S結構，連線資料庫的使用者可以不同，所以安全機制有用；但是在web的三層

架構中，資料庫使用者不是給使用者用的，所以基本上，只有一個使用者，擁有所有許可權（最多還有一個開發使用者）。這個時候，安全機制有點多餘。     
  5.   使用者滿意：實際上這個只是要將訪問資料庫的介面統一，是用儲存過程，還是EJB，沒太大關係，也就是說，在三層結構中，單獨設計出一個數據訪問層，同樣能實現這個目標。     
  6.   開發除錯：一樣由於IDE的問題，儲存過程的開發除錯要比一般程式困難（老版本DB2還只能用C寫儲存過程，更是一個災難）。     
  7.   移植性：算了，這個不用提，反正一般的應用總是繫結某個資料庫的，不然就無法靠優化資料庫訪問來提高效能了。     
  8.   維護性：的確，儲存過程有些時候比程式容易維護，這是因為可以實時更新DB端的儲存過程，但是在3層結構下，更新server端的資料訪問層一樣能實現這個目標，可惜現在很多平臺不支援實時更新而已。     
    
  從上面可知道，儲存過程的使用不能有死規定（全用，或全不用），以前Terminal   -   Server,   Client-DB的方式已經過時了，儲存過程很多優勢已經不明顯。     
  現在，我認為的原則是：所有資料訪問在應用層封裝為資料訪問層，在那裡，如果SQL簡單的話，直接用SQL；如果SQL複雜，或者資料互動多且中間資料最後不會用到，使用儲存過程。其他憑經驗吧。

儲存過程是由一些SQL語句和控制語句組成的被封裝起來的過程，它駐留在資料庫中，可以被客戶應用程式呼叫，也可以從另一個過程或觸發器呼叫。它的引數可以被傳遞和返回。與應用程式中的函式過程類似，儲存過程可以通過名字來呼叫，而且它們同樣有輸入引數和輸出引數。 

　　根據返回值型別的不同，我們可以將儲存過程分為三類：返回記錄集的儲存過程，返回數值的儲存過程（也可以稱為標量儲存過程），以及行為儲存過程。顧名思義，返回記錄集的儲存過程的執行結果是一個記錄集，典型的例子是從資料庫中檢索出符合某一個或幾個條件的記錄；返回數值的儲存過程執行完以後返回一個值，例如在資料庫中執行一個有返回值的函式或命令；最後，行為儲存過程僅僅是用來實現資料庫的某個功能，而沒有返回值，例如在資料庫中的更新和刪除操作。 

　　使用儲存過程的好處 

　　相對於直接使用SQL語句，在應用程式中直接呼叫儲存過程有以下好處： 

　　(1)減少網路通訊量。呼叫一個行數不多的儲存過程與直接呼叫SQL語句的網路通訊量可能不會有很大的差別，可是如果儲存過程包含上百行SQL語句，那麼其效能絕對比一條一條的呼叫SQL語句要高得多。 

　　(2)執行速度更快。有兩個原因：首先，在儲存過程建立的時候，資料庫已經對其進行了一次解析和優化。其次，儲存過程一旦執行，在記憶體中就會保留一份這個儲存過程，這樣下次再執行同樣的儲存過程時，可以從記憶體中直接呼叫。 

　　(3)更強的適應性：由於儲存過程對資料庫的訪問是通過儲存過程來進行的，因此資料庫開發人員可以在不改動儲存過程介面的情況下對資料庫進行任何改動，而這些改動不會對應用程式造成影響。 

　　(4) 布式工作：應用程式和資料庫的編碼工作可以分別獨立進行，而不會相互壓制。 

優點： 
1.由於應用程式隨著時間推移會不斷更改，增刪功能，T－SQL過程程式碼會變得更復雜，StoredProcedure為封裝此程式碼提供了一個替換位置。 

2.執行計劃（儲存過程在首次執行時將被編譯，這將產生一個執行計劃－－ 實際上是 Microsoft SQL Server為在儲存過程中獲取由 T-SQL 指定的結果而必須採取的步驟的記錄。）快取改善效能。 
........但sql server新版本，執行計劃已針對所有 T-SQL 批處理進行了快取，而不管它們是否在儲存過程中，所以沒比較優勢了。 

3.儲存過程可以用於降低網路流量，儲存過程程式碼直接儲存於資料庫中，所以不會產生大量T-sql語句的程式碼流量。 

4.使用儲存過程使您能夠增強對執行計劃的重複使用，由此可以通過使用遠端過程呼叫 (RPC) 處理伺服器上的儲存過程而提高效能。RPC 封裝引數和呼叫伺服器端過程的方式使引擎能夠輕鬆地找到匹配的執行計劃，並只需插入更新的引數值。 

5.可維護性高，更新儲存過程通常比更改、測試以及重新部署程式集需要較少的時間和精力。 

6.程式碼精簡一致，一個儲存過程可以用於應用程式程式碼的不同位置。 

7.更好的版本控制，通過使用 Microsoft Visual SourceSafe 或某個其他原始碼控制工具，您可以輕鬆地恢復到或引用舊版本的儲存過程。 

8.增強安全性： 
a、通過向用戶授予對儲存過程（而不是基於表）的訪問許可權，它們可以提供對特定資料的訪問； 
b、提高程式碼安全，防止 SQL注入（但未徹底解決，例如，將資料操作語言－－DML，附加到輸入引數）； 
c、SqlParameter 類指定儲存過程引數的資料型別，作為深層次防禦性策略的一部分，可以驗證使用者提供的值型別（但也不是萬無一失，還是應該傳遞至資料庫前得到附加驗證）。 



缺點： 

1.如果更改範圍大到需要對輸入儲存過程的引數進行更改，或者要更改由其返回的資料，則您仍需要更新程式集中的程式碼以新增引數、更新 GetValue() 呼叫，等等，這時候估計比較繁瑣了。 

2.可移植性差 

由於儲存過程將應用程式繫結到 SQL Server，因此使用儲存過程封裝業務邏輯將限制應用程式的可移植性。如果應用程式的可移植性在您的環境中非常重要，則將業務邏輯封裝在不特定於 RDBMS 的中間層中可能是一個更佳的選擇。 


區別一，儲存過程儲存在資料庫裡面，儲存過程可以被連線此資料庫的所有程式設計語言和程式使用，自定義函式不能。 

區別二，儲存過程可以有資料庫管理軟體修改，使得多層結構程式調整系統邏輯時，並不需要編譯和分發程式。 

區別三，儲存過程執行中，不會引起網路流量，不佔用程式伺服器的記憶體和CPU資源。