ケース:T1フォームからの送信の記録を保持するテーブルがあります。このテーブルのレコードを更新する際に、 table に行を挿入したいと考えていますT2。
この場合、次のシナリオのパフォーマンスはどのようになりますか?
シナリオ A:AFTER UPDATE ON T1トリガーが関連する行を作成して挿入します。T1には への参照がないのでT2、これで問題ありません。
シナリオ B: サーバー側のサービス レイヤー (PHP、Python など) は、更新後に関連する行を挿入します。
シナリオ C: これはストアド プロシージャですが、SP とトリガーの比較が多数あるため、それらを含める必要はありません。
私は本当にトリガーのファンではありません。問題は、それらが本質的に副作用であり、そのため、システムの将来のメンテナには隠されて明白ではない傾向があるということです。それらは後で誤ったコードにつながります。この特定のユースケースのパフォーマンスのボトルネックを示す特定のデータがない限り、データベースへのすべてのアクセスを処理するストアドプロシージャまたは「PHP、Python、その他」のサービスレイヤーのいずれかを確認することをお勧めします。正確さがパフォーマンスよりも重要であるという事実を見失うことはありません。
トリガーとPythonのどちらかを選択できるので、トリガーを選択します。データのトリガーにより、アプリケーションに依存するのではなく、データの挿入方法に関係なく、T2にT1のレコードが含まれるようになり、データの整合性が確保されます。T1にレコードを追加する別のアプリケーションをトリガーを使用して追加した場合でも、T2はレコードを挿入します。
ただし、なぜストアドプロシージャを割引するのか、トリガーがより高速である、または「データベースサーバーの性質により適している」という考えをどこで得るのかはわかりません。
データが常にT1アプリケーションを介してのみ更新されることを保証できる場合は、コード (PHP/Python またはストアド プロシージャ) で行うことに投票します。データが別の方法で更新される可能性がある場合 (DBA がクエリを作成するなど)、トリガーを使用して、期待どおりの一貫した結果が得られることを保証します。
トリガーやストア プロシージャの使用に関係なく、SQL コードは事前にコンパイルおよび最適化されています。パフォーマンスに大きな利点があるとは思えません。他の人が指摘しているように、トリガーは、テーブルの複数のレコードを更新するときに偶発的なパフォーマンスの問題を引き起こしたり、更新チェーンの管理が困難になる可能性があります。
一連のトリガーよりも、ストアド プロシージャのリファクタリングと保守がはるかに簡単になります。