Aのトリガーに何かを実行させて、Bのトリガーに起動する必要がないことを警告することができます。セッションにいくつかの状態を設定したいというさまざまな要望があります。考えられる最も簡単なアプローチは、ブール変数bypass_checks_on_bを使用してパッケージを作成するようなことです。 TRUEに設定したもの UPDATEを実行する前に Aで、FALSEに設定します 一度UPDATE 完了し、検証を行う前に、Bのトリガーでこの変数の状態を確認します。パッケージを使用するのではなく、一時テーブルまたはコンテキストでも同様のことを行うことができます。効率が低下すると、Bのトリガー内のコールスタックを解析して、Aのトリガーがコールスタック内にあるかどうかを確認できますが、それはかなり見苦しい傾向があります。
ただし、このアーキテクチャ全体については非常に慎重になります。 Aにトリガーがあり、Bのトリガーを起動して、Aにクエリを実行したい場合は、ほとんどの場合、トリガーにロジックを入れすぎているため、移動するほうがはるかに便利です。そのロジックは、アプリケーションが直接挿入または更新を行うのではなく、呼び出すことができるストアドプロシージャレイヤーに組み込まれます。トリガーにロジックを押し込みすぎると、さまざまなステートメントがどのような副作用をもたらすかがアプリケーションコードを見ると明らかでないため、システムを理解するのが非常に困難になります。そして、呼び出し元に応じて1つのコードを通る多くのパスがある非常にステートフルなコードになります。これはほぼ間違いなく、コードが予期しないことをしていることに気付く場所をテストしない、または考えないという状態が発生することを意味します。大量の状態を持つことと、大量の副作用を伴うコードベースを持つことの間で、本質的に保守不可能なコードベースを非常に迅速に構築できます。