儲存過程的優缺點

：

儲存過程優點：

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 的中間層中可能是乙個更佳的選擇。

3. 大量採用儲存過程進行業務邏輯的開發致命的缺點是很多儲存過程不支援物件導向的設計，無法採用物件導向的方式將業務邏輯進行封裝，從而無法形成通用的可支援復用的業務邏輯框架。

4.**可讀性差,相當難維護.