DB trigger 很方便，資料改變時就會觸發，而且還可以拿到 old value 跟 new value，比起在 AP 層方便許多
這些好用的功能很容易誘導工程師進入誤區
講一個例子，我曾經做過電商的系統，裡面有個邏輯是當付款成功後要將訂單 mark 為等待出貨
當下覺得這種資料改變要引發一個行為用 trigger 最方便，結果搞死自己
因為這個需求屬於商業邏輯，商業邏輯會隨需求變動
結果業主更改付款成功的邏輯，也有增加一些限制條件，當缺貨的情況下，就把訂單 mark 成缺貨中
邏輯寫在 trigger 裡面，不僅除錯困難，trigger 的語法也讓程式不好閱讀
經過一輪 trigger 的洗禮，悟出適合使用 trigger 的情境，就是用來 derive
一樣是電商的系統，業主希望客戶列表可以顯示這個客戶的購買次數、購買金額
簡單做就是去 join 訂單的 table 就可以，但是因為訂單的 table 資料很多，join 速度有些慢，所以後來用 trigger，當訂單 table 有改變時，就透過 trigger count and update 客戶資料，這樣在讀取客戶列表就不用再 join，同時當計算邏輯有修改時可以透過 update 語法整批更新
也就是說這個欄位的資料其實是一種快取，透過 trigger 來更新快取
所以如果你的需求是不牽涉商業邏輯，只做 derive 那 trigger 就很適合
