大型系統必須得要儲存過程和觸發器嗎？

1樓：ggffss

都不是必須的。

觸發器一般不建議用（看具體需求）。

但是儲存過程在處理發雜業務邏輯的時候就很有用。

幾十張表各種巢狀條件關係，各種奇葩的處理，感覺就是要比orm強很多。

主要是效能，用 orm的話可能要來來回回撈資料。

2樓：Gavin Wu

1 PLSQL可以大大降低parse/exec 百分比2 儲存過程可以自動完成靜態SQL variable bind3 儲存過程大大減少了JDBC網路傳輸與互動，速度快4 oracle 中儲存過程內部commit為非同步寫，一定程度上減少了等redo日誌落地時間

5 儲存過程最大問題就是給資料庫開發工作壓力太大，另外架構公升級時候會比較難解耦

6 觸發器不推薦使用，觸發操作能在業務層解決就在業務層解決，否則很難維護，而且容易產生死鎖

3樓：Abioy

做過不同型別的專案，可以理解使用/不使用兩種行為。

1）對於傳統業務（比如單機應用、PC軟體、ERP等），已經有了這麼好用的feature，為毛我不用？節省大量開發成本；

2）對於較大的金融類系統，因為資料敏感，還是可以看到大量的事務、儲存過程等使用的情況，上了量的系統，可能只會少量、簡化、區域性使用這些技術，輔以事後的對賬；

3）對於網際網路業務，主要指上了量的網際網路業務，一般只使用簡單功能，不使用事務、儲存過程等，只使用最簡單的介面功能；

給團隊內外培訓時，我經常會告訴他們，這是由不同業務、不同場景、不同需求造成，然後就話題就又回到架構設計的折衷上來。沒錯，我把自己的理解說出來，但是我還有一點不經常說——

世界上要是特麼有乙個能應對高併發、分布式場景下的儲存服務，碰巧全域性事務、儲存過程你隨便寫都能自動優化，滿足你的要求，還居然免費？！誰會不用呢？沒看大家都眼紅Spanner嗎

以前老說NOSQL替代關係型，要是MySQL性能夠、自動分割槽分片、支援高效能的全域性事務、跨機房等等一應概全，有哪個會不用？（當然，光速擺在那，通訊該花的時間少不了）

所以，沒說的那一點是：這不是因為當前這些服務都不夠好用嗎。

4樓：

應該具體到特定的業務場景中。我服務過的金融企業儲存過程還是有用的，且儲存過程使用很多。pl/sql程式設計要求性很高。對外提供統一訪問介面。

觸發器用的不多，盡量避免。

5樓：Gary Chen

可以用,如果你很明確自己的容量和效能,很熟悉儲存過程的開發.說點其他的:

1. 隨著海量的資料增長,高併發的系統,資料庫慢慢轉化為僅僅作為資料的容器. 如果你的資料庫存在瓶頸,儲存器,觸發器這些都沒用了.

2. 從web層擴充套件是很容易的.所以把計算留給web層吧.

6樓：

不是說必須得用，原則是視情況而定，不要濫用。儲存過程還可以，觸發器盡量少用會影響執行效率，特別是對於高頻率大量更新的table而言。

7樓：李健富

肯定不能一刀切的說能用或者不能用，不同型別的系統、不同的規模、不同的歷史原因都會有不同的解決方案。

一般情況下，Web應用的瓶頸常在DB上，所以會盡可能的減少DB做的事情，把耗時的服務做成Scale Out，這種情況下，肯定不會使用儲存過程；而如果只是一般的應用，DB沒有效能上的問題，在適當的場景下，也可以使用儲存過程。

至於觸發器，我是知道有這東西但從來沒用過。我希望風險可控，遇到問題能夠快速的找到原因，盡可能不會去使用觸發器。