案例：我有一個表T1保留通過表單提交的記錄。在對此表上的記錄進行更新時，我想向表T2插入一行。SQL觸發器與服務器端查詢
對於這種情況，以下情況的性能如何比較？
場景A：AFTER UPDATE ON T1觸發器構建並插入相關行。由於T1沒有提及T2，所以這樣可以。
場景B：服務器端服務層（PHP，python，whatever）在更新後插入相關行。場景C：這將是存儲過程，但SP和觸發器有很多比較，所以你不必包含它們。
鑑於觸發器和python之間的選擇，我會選擇觸發器。您的數據觸發器確保T2無論數據如何插入都包含T1記錄，而不是依賴於應用程序，從而確保您的數據的完整性完整性。如果添加另一個向T1添加記錄的應用程序，並帶有觸發器，T2仍然會插入記錄。
我不知道爲什麼你折扣，雖然存儲過程，也不是你在哪裏得到的想法，觸發更快或「更適合於數據庫服務器的性質」
謝謝。正如Joe提到的那樣，誠信是一個非常重要的問題，觸發器可以消除很多風險。 –
至於我得到的想法，大部分來自我在5分鐘左右在SO和其他幾個地方閱讀的內容。說：「我知道（...）」可能有點太強大了，是的。 –
我真的不是觸發器的粉絲。問題在於，它們本質上就是副作用，因此往往對系統的未來維護者隱藏起來並不明顯。他們以後會導致錯誤的代碼。除非你有具體的數據顯示這個特定用例的性能瓶頸，否則我更願意看到處理所有數據庫訪問的存儲過程或者「PHP，python，不管」服務層。千萬不要忘記正確性勝過性能這一事實。
+1服務層 – MiMo
謝謝，是的，通過服務層完成工作就是我的意思。最後三個字使它非常簡單（不過分）。 –
如果你能保證數據始終並且只通過您的應用程序在T1更新，我會投票支持在代碼中執行它（PHP/Python或存儲過程）。如果有可能以其他方式更新數據（DBA可能會編寫一個查詢，或許？），那麼使用觸發器來保證您獲得期望的一致結果。
非常感謝您指出保證更新是通過服務層是一個重要的關注。 –
無論使用觸發器和/或存儲過程，您的sql代碼都是預編譯和優化的。我懷疑有一個顯着的性能優勢。正如其他人所指出的那樣，觸發器在更新表上的多個記錄時可能會導致意外的性能問題，或者導致難以管理更新鏈。
與鏈條觸發器相比，您將更容易重構和維護存儲過程。
在觸發器中查找錯誤可能很痛苦，因爲它們可能會混淆信息。如果你的情況允許，我會去做程序（更容易測試一件事） – davek