管理されたSQLトリガー再帰

Question

トリガーが割り当てられたテーブルがあります。そして、このトリガーは同じテーブルデータを変更します。確かに、これは新しいトリガを開始します。

すべてのトリガインスタンスは、チェーン内の最後のトリガインスタンスであるかどうかを知っています（いくつかのルールがあります）。それが必要な場合は、次のトリガーをオフにする必要があります。

私は状態（例えば、停止フラグ）があると、予期しない動作が起こる可能性があります。たとえば、ユーザーがテーブルを変更します。新しいトリガチェーンが開始されています。トリガはターミネータになり、停止フラグを立てたい。この瞬間、別のユーザがテーブルを変更して、新しいトリガチェーンが開始され、それが実行されなければならない。しかし、停止フラグが設定されると、フラグをクリアして終了します。さて、再帰的なトリガー（これは私たちは考える）が開始され、フラグがクリアされているかどうかを調べます...実行されます！

私はわかりませんが、このような場合の順序は何ですか？データを変更した直後に再帰トリガが実行されるか、親プロセスが最初に完了するかどうかはわかりません。

よろしく、

Answer 1

は、複雑なトリガを捨てると、ストアドプロシージャ、または可能な場合は、標準のSQLセットベースの操作のいずれかにすべてを簡素化することを検討してください。

ストアドプロシージャは、特定のテーブルにトリガーの多くのレイヤーを理解して維持するのが簡単です。トリガーにはいくつかのシナリオでは価値がありますが、トリガーの連鎖を呼び出すトリガーがある場合や、データに依存するトリガーが同じテーブルにある他のトリガーから変更されている場合は、メンテナンスの悪夢。 SQLの更新/挿入ステートメントを改善するか、トリガーをある種のストアドプロシージャにリファクタリングすることによって、開始点として単純化します。