以下是內部的關於觸發器和存儲過程的郵件溝通內容，反映了對觸發器和存儲過程的支持和反對雙方的觀點。
---------------------------------------------------------------------------------
部分觀點和你不同。你說的在項目上的坑，不能甩鍋觸發器。
1，觸發器和java代碼沒有本質的區別，不同的語言而已。用和不用，數據庫該做的事情1點沒少，一個在java程序里發起sql，一個在觸發器執行。所以觸發器不會給數據庫帶來任何性能和並發問題
2，觸發器和存儲過程性能是高的，這是其主要的優勢所在，他是預編譯的，而且省掉了和數據庫建立連接和通訊的成本
3、觸發器和存儲過程不會比寫得很爛的java代碼帶來的副作用更大。
4、觸發器和存儲過程也是代碼的一部分。從這個意義上講，不用觸發器，同樣存在升級的問題。這不是觸發器的問題，是開發管理問題。
使用觸發器和存儲過程也有缺點：
1，將業務邏輯打散了，一部分在java代碼，一部分在數據庫。增加了開發管理的難度，這是它的弊端。
2，不是面向對象的，是面向過程的。
3、數據庫遷移變復雜了。
任何技術都是有利有弊，綜合比較，我認為使用觸發器和存儲過程是有他的適用場景。我以前也反對使用觸發器和存儲過程，現在不一樣了。
From: ▓▓▓▓▓▓▓▓▓▓
Sent: Thursday, December 26, 2019 11:44 PM
To: ▓▓▓▓▓▓▓▓▓
Subject: 回復: 關於數據修改日志的一個觸發器實現方案
存儲過程、觸發器 ，我們不提倡，更不建議在數據庫上做任何觸發器操作，觸發器會給數據庫本身帶來性能問題，並發大了甚至會拖垮數據庫，同時后期的運維升級的人員，如果沒有全面了解相關觸發器，可能會出現運維障礙，曾經在多個項目上踩過坑，包括xx、xx的資金等采用的觸發器也都取消了。
大型集團，高並發的應用，數據庫越簡單約好。
建議盡量使用程序替代數據庫觸發器。數據庫的意義，目前就是存儲。數據庫的作用越來越低了，彈性配置，資源配置都在Web端。數據庫就僅僅是執行存儲而異。