トリガー設計のガイドライン

• トリガーを使用して、特定のイベントが発生するたびに(どのユーザーまたはアプリケーションがトリガーを起動する文を発行するかにかかわらず)必要なアクションが実行されることを保証します。

  たとえば、トリガーを使用して、いずれかのユーザーが表を更新するたびにそのログ・ファイルが更新されることを保証します。

• データベース機能が重複するトリガーは作成しないでください。

  たとえば、制約で同じ処理ができるときに、無効なデータを拒否するためのトリガーは作成しないでください(「トリガーと制約の違い」を参照)。

• SQL文が行を処理する順序(変化する可能性あり)に依存するトリガーは作成しないでください。

  たとえば、グローバル・パッケージ変数の現行の値が、行トリガーによって処理される行に依存する場合は、行トリガー内のその変数に値を代入しないでください。グローバル・パッケージ変数がトリガーによって更新される場合は、それらの変数をBEFORE文トリガー内で初期化してください。

• 行データがディスクに書き込まれる前に行を変更するために、BEFORE行トリガーを使用します。

• 行IDを取得して、それを操作で使用するために、AFTER行トリガーを使用します。

  トリガーを起動する文によってORA-02292エラーが発生すると、AFTER行トリガーが起動されます。

  ノート:

  AFTER行トリガーを使用すると、BEFORE行トリガーより少し効率が上がります。BEFORE行トリガーでは、影響を受けるデータ・ブロックを最初にトリガーのために読み取り、次にトリガーを起動する文のために読み取ります。AFTER行トリガーでは、影響を受けるデータ・ブロックをトリガーのためにのみ読み取ります。

• BEFORE行トリガーのトリガーを起動する文が、実行中のUPDATE文と競合するUPDATE文またはDELETE文である場合、データベースによって、SAVEPOINTまでの透過的ROLLBACKが実行され、トリガーを起動する文が再開されます。データベースでは、トリガーを起動する文が正常に完了するまでこの処理が何回も行われる可能性があります。データベースによってトリガーを起動する文が再開されるたびに、トリガーが起動されます。SAVEPOINTまでのROLLBACKでは、トリガーが参照するパッケージ変数への変更は取り消されません。各再起動で不要な副作用が発生しないようにするには、BEFORE行トリガーが冪等であることを確認します。つまり、後続の各実行で結果が変わらないようにトリガーを記述する必要があります。繰り返さない追加作業は、AFTER行トリガーで処理できます。この状況を検出するには、パッケージにカウンタ変数を含めることもできます。

• 再帰トリガーは作成しないでください。

  たとえば、トリガーが定義されている表に対してUPDATE文を発行するAFTER UPDATEトリガーは、作成しないでください。このトリガーは、メモリー不足になるまで再帰的に起動し続けます。

• リモート・データベースにアクセスする文が含まれるトリガーを作成する場合、その文の例外ハンドラをストアド・サブプログラムに配置し、そのサブプログラムをトリガーから起動してください。

  詳細は、「リモート例外処理」を参照してください。

• DATABASEトリガーは慎重に使用してください。このトリガーは、データベース・ユーザーがトリガー・イベントを開始するたびに起動されます。

• トリガーが次の文を実行すると、文によってトリガーの所有者は戻されますが、表を更新しているユーザーは戻されません。

  SELECT Username FROM USER_USERS;
  

• コミットされたトリガーのみが起動されます。

  トリガーは、それを作成するCREATE TRIGGER文が成功した後に、暗黙的にコミットされます。したがって、トリガーを作成する次の文では、そのトリガーを起動できません。

  CREATE OR REPLACE TRIGGER my_trigger
    AFTER CREATE ON DATABASE
  BEGIN
    NULL;
  END;
  /
  

• 同じ表に対するトリガーを持つアプリケーションのインストールをモジュール化するには、一連の操作を実行する単一のトリガーではなく、同じ型の複数のトリガーを作成します。

  各トリガーは、前に起動されたトリガーによって変更された内容を参照します。各トリガーは、OLDおよびNEWの値を参照できます。