（1） 針對較為復雜的跨多表的數據業務級別的約束，可以通過觸發器來替代大量的後台判斷代碼，效率較高且便捷。
（2） 如果想通過觸發器輔助業務邏輯，不能單著眼於數據庫內容的變化來設計觸發器，還必須緊密結合業務模型中涉及該表的所有地方，因為很有可能因為不一致的邏輯處理方式導致我們設計的觸發器遺漏下一些分支條件！其實，在這種情況下，如果能有更好的方法，不建議使用觸發器，因為牽扯到過多的業務邏輯內容的話，會使觸發器的設計和編寫困難重重，不能充分發揮其便捷高效的優點。
（3） 鑒於觸發器在實際運行的時候，是被包含在一個數據庫事務中的，所以我們在編寫了完整的處理分支後，就可以完全信賴它的執行，大量並發情況下，數據庫會自動處理好對各事務的操作，不用擔心觸發器的性能和正確性。
（4） 在同一個事務中的不同執行語句，如果後面語句中的操作觸發了相應表的觸發器，則在觸發器內可以查看前面語句執行後的結果列表的內容，所以，在使用觸發器的時候，對事物中多條語句的操作的順序是要考慮清楚的。
（5） 如果我們使用觸發器+數據表的形式來對數據進行一些統計性的操作的時候，我們在保證觸發器邏輯完整性的前提下，最好能通過數據庫任務的方式來定時進行檢查，因為觸發器對於一個用程序的操作都能有相應的處理，但對於人為的數據庫操作有時卻是無能為力的，所以，為了避免這樣的錯誤發生，有必要對統計結果做定期的校驗，保證數據的正確性，當然，如果可以，盡量不要使用這種方法，但在一些個性化項目中，因為一些特別的原因，可能會有所應用。
（6） 我們可以間接地通過更新數據表的方式來調試觸發器，當然，也可以通過在觸發器中添加一些“特殊的日志性質的更新語句”來輔助我們的調試。
最後再說一句，所謂“好鋼用在刀刃上”，觸發器在一些特殊的應用情況下，會極大地簡化我們的開發工作量，並提升處理效率，但是它並使萬能的，也不是適用於各種應用環境，所以我們使用的時候，一定要慎重，更要權衡利弊。
