ここでトリガーを使用することは、問題を引き起こすだけです。
さらに、スケジュールされたジョブはコミットされたデータしか表示できないため、スケジューラーを使用するという選択はおそらく最善のアイデアではありません。したがって、トランザクションロジックをウィンドウの外にスローするトリガーをコミットするか、テーブルへの変更がトランザクションの終了まで遅延されます。
次のいずれかを行う必要があります：
-
手順を使用します。最も簡単な答え。複数のアプリケーションがある場合、それらはDML /ビジネスロジックを直接実行するべきではありません。それらはすべて同じコードを実行するように、常にプロシージャを使用して実行する必要があります。許可またはビューを使用した直接DMLを禁止します。
INSTEAD OFを介してプロシージャの使用を強制する必要がある場合があります ビューでトリガーします（これは、アプリケーションを変更できない場合にのみ検討してください）。 -
おそらく、あなたの場合の手順よりも優れています。重複データを含まないスキーマを使用してください。冗長データを保存する必要はありません。これにより、アプリケーション開発が必要以上に複雑になります。パフォーマンス、リソース、エネルギーの観点から、問題を解決する最善の方法は、タスクが不要であることに気付いたときです。
モデルの説明から、削除できる列は次のとおりです。
- task.duration_in_days
- task.end_date
- task.needs_recomputation
- subtask.start_date
- subtask.end_date
taskテーブルには開始日のみが含まれ、各サブタスクにはその期間のみが格納されます。集計情報が必要な場合は、結合を使用してください。ビューを使用して、アプリケーションがデータに透過的にアクセスできるようにすることができます。 -
変更トリガーの回避策 を使用します パッケージ変数を使用して、変更された行を
BEFOREで識別します。 およびAFTERステートメントトリガー。明らかに、これにはコーディング、テスト、保守が難しい多くのコードが含まれるため、代わりに可能な限りオプション（1）と（2）を使用する必要があります。