當一個事務涉及到多個SQL語句時或者涉及到對多個表的操作時就要考慮用儲存過程；當在一個事務的完成需要很複雜的商業邏輯時（比如，對多個數據的操作，對多個狀態的判斷更改等）要考慮；還有就是比較複雜的統計和彙總也要考慮，但是過多的使用儲存過程會降低系統的移植性。

儲存過程（Stored Procedure）是在大型資料庫系統中，一組為了完成特定功能的SQL 語句集，儲存在資料庫中經過第一次編譯後再次呼叫不需要再次編譯，使用者通過指定儲存過程的名字並給出引數（如果該儲存過程帶有引數）來執行它。儲存過程是資料庫中的一個重要物件，任何一個設計良好的資料庫應用程式都應該用到儲存過程。

當一個事務涉及到多個SQL語句時或者涉及到對多個表的操作時就要考慮用儲存過程；當在一個事務的完成需要很複雜的商業邏輯時（比如，對多個數據的操作，對多個狀態的判斷更改等）要考慮；還有就是比較複雜的統計和彙總也要考慮，但是過多的使用儲存過程會降低系統的移植性。

為了系統的控制方便，例如當系統進行調整時，這是隻需要將後臺儲存過程進行更改，而不需要更改客戶端程式。也無需重新安裝客戶端應用程式。

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

優點：
1.速度快。尤其對於較為複雜的邏輯，減少了網路流量之間的消耗
我有的過程和函式達到了幾百行，一個微型編譯器，相信用程式就更麻煩了。
2.寫程式簡單，採用儲存過程呼叫類，呼叫任何儲存過程都只要1-2行程式碼。
(我不知道別人怎麼呼叫，我是深受其益）
3.升級、維護方便
4.除錯其實也並不麻煩，可以用查詢分析器
5.如果把所有的資料邏輯都放在儲存過程中，那麼asp.net只需要負責介面的顯示阿什麼的，出錯的可能性最大就是在儲存過程。我碰到的就一般是這種情況。

缺點：
1.可移植性差，我一直採用sql server開發，可是如果想賣自己的東西，發現自己簡直就是在幫ms賣東西，呵呵。想換成mysql，確實移植麻煩。
2.採用儲存過程呼叫類，需要進行兩次呼叫操作，一次是從sql server中取到過程的引數資訊，並且建立引數；第二次才是呼叫這個過程。多了一次消耗。
不過這個缺點可以在專案開發完成，過程引數完全確定之後，把所有過程引數資訊倒入到一個xml檔案中來提高效能。

當一個業務同時對多個表進行處理的時候採用儲存過程比較合適。

1. 使用儲存過程在一般情況下會提高效能，因為資料庫優化了儲存過程的資料訪問計劃並應用快取方便以後的查詢；
2. 儲存過程單獨保護存在於資料庫中。客戶端可以獲取許可權執行儲存過程,而不需要對底層的具體表設定其他的訪問許可權；
3. 儲存過程會使得維護起來更加方便，因為通常修改一個儲存過程要比在一個已經發布的元件中修改SQL語句更加方便；
4. 儲存過程給底層資料格式增添了額外的抽象層。使得使用儲存過程的客戶端對儲存過程的實現細節以及對底層資料格式是隔離獨立的；
5. 儲存過程能夠緩解網路頻寬，因為可以批量執行SQL語句而不是從客戶端傳送超負載的請求。

複雜的資料處理用儲存過程，如有些報表處理

多條件多表聯合查詢,並做分頁處理

( 轉載)

------------------------------------------------------------------------------------------------------------------------

說白了，就是業務邏輯部署在哪裡的問題。部署在資料庫，程式裡當然只有數行的呼叫程式碼，當然是這種做法有一定好處，如減少了客戶端的運算壓力等，但好壞是相對的，就拿這點來說，客戶端壓力少了，服務端壓力就會變大，好

與非好不是一個人說了算的，要考慮技術和物理支撐多方面因素，當然我認為主要是技術上的問題佔主導，偏向資料庫技術的人一般喜歡儲存過程，這沒絕對的對錯，但別太過偏執自己的觀點。然而對於基於.NET開發的程式設計師，程式程式碼

是主，資料庫是次，次只是附屬，而不是必需品，眾多額.NET開發人員還是應該把業務邏輯寫在.NET程式碼上，以便業務邏輯在不斷更替的技術中重用。反之，專案經理今天用關係型資料庫來支撐專案，明天也可以用NoSQL,甚至是

XML，TXT之流作為持久化介質。當然更換持久化介質的頻率不會很頻繁，但如果真要算一算生命週期，也不會很長，除非你的工作生涯是和公司繫結死，並且公司是不會普及新技術的會一直用關係型資料庫到永遠。我想沒人會這麼傻

吧？就算你願意，公司也不一定堅持到你退休。看待這個問題要放長雙眼，而不是墨守成規，沾沾自喜。

------------------------------------------------------------------------------------------------------------------------------------

團隊的技術背景問題。。。儲存過程效率上的優勢還是有的

------------------------------------------------------------------------------------------------------------------------------------

FROM: http://www.360doc.com/content/13/0513/17/3776353_285164496.shtml#