データテーブルへの変更がジョブの作成とそれに続くハンドラーによる処理（perlで記述され、チャネルを介して通知される）をトリガーするアーキテクチャーがあります。ジョブの処理中に、ハンドラーでデータテーブルを更新する必要が生じます。再帰を回避するために、次のことを行います。
- 更新前にトリガーを無効にする必要があります
- 更新を行い、
- トリガーを再度有効にします。
プロジェクトの存続期間の後半に新しいハンドラーが追加される可能性があるため、トリガーの無効化と有効化が忘れられる可能性があり、これが保守の問題になる可能性があります。
別のアプローチとして、トリガーの範囲をフロントエンド固有のビューに制限するというアイデアを考案しました。instead ofこれらのビューは、トリガーによって書き込み可能になります（この質問も参照してください）。ハンドラーは、ジョブの実行中にデータテーブルを直接更新するため、再帰的なジョブはトリガーされません。このアプローチの実用的な実装があります。
私の意見では、ここでは複雑さをトレードします。アルゴリズム（無効化トリガーを有効化）と構造的（追加ビュー）を交換します。私たちは現在後者を選ぶ傾向がありますが、私はあなたたちからこの問題についていくつかの意見を求めました...これは健全なアプローチですか？