トリガー - 推奨事項と禁止事項

推奨事項

• トリガーが関与する複雑なアプリケーションを実装する前に、トリガーを使用して小規模なテスト・ケースを試し、満足できる結果および動作が得られることを確認してください。

• (トリガーが関連付けられた)データ・ディクショナリ内のフィールドのタイプまたは長さを変更したときは、必ず以下を再コンパイルしてください。

• そのフィールドに関連付けられたすべてのトリガー・ファンクション

• そのフィールドを実際または仮想の列として含むテーブルのすべてのオブジェクト・アクセス・モジュール

• そのフィールドを含むテーブルに対して*DBOPTIMIZE参照を行うすべてのファンクション

• 再コンパイルするオブジェクトのリストは、フィールドの定義の完全なリストを生成することによって簡単に得られます。

• (トリガーが関連付けられた)データベース・テーブルのレイアウトを変更した場合は、必ず以下を再コンパイルしてください。

• そのテーブルのオブジェクト・アクセス・モジュール

• そのテーブルに関連付けられたすべてのトリガー・ファンクション

• そのテーブルに対して*DBOPTIMIZE参照を行うすべてのファンクション

再コンパイルするオブジェクトのリストは、ファイルの定義の完全なリストを生成することによって簡単に得られます。

禁止事項

• トリガーが関連付けられているテーブルに対してI/Oを実行しないでください。直接または間接を問わず、このようなI/Oを実行しようとすると、ファイルのオブジェクト・アクセス・モジュールが再帰的に呼び出されることがあります。この規則を回避するために、*DBOPTIMIZEを使用しないでください。アクティブなオブジェクト・アクセス・モジュールのテーブル・カーソルが失われたり壊れたりする可能性があります。

• 実際および仮想の列の数が799個(800番目の列位置は、標準の@@UPIDフィールド用に予約済み)を超えているテーブルに対してトリガーを使用しないでください。

• トリガーにより、過度にリソースを消費しないようにしてください。例えば、テーブルからの読み取り後に必ず実行される無条件のトリガーがデータベース・アクセスを3回実行する場合、ベース・テーブルの読み取りに要する時間は少なくとも4倍になります。トリガーは非常に便利な機能ですが、魔法ではありません。多くの処理を実行するようトリガーを設定すると、それに伴ってスループットが低下します。トリガーは、アプリケーション設計者の責任において、その使用によるアプリケーション・スループットへの影響を考慮した上で使用してください。

• トリガー間に依存関係を作成しないでください。例えば、トリガーA (UPDATE前)によってフィールドXの値を設定するとします。トリガーB (同じくUPDATE前)を、最初にトリガーAが実行されている(これによってフィールドXが設定されている)ことを「認識」した上で、トリガーAの後に実行するよう設定することはお勧めしません。これは、トリガー間の「相互依存」の一例で、トリガーの使用方法として適切ではありません。この場合、トリガーA内の、フィールドXに値を設定する処理の後に、トリガーBのロジックを直接挿入してください。

• トリガー・ファンクションからユーザー出口が呼び出されたときにABORTを使用しないでください。トリガー・ファンクション内でABORTが実行されると、オブジェクト・アクセス・モジュールがABORTを中断できるようになり、ファンクションにトリガー・エラー状況を渡します。ただし、トリガーによって呼び出された(ユーザー出口)ファンクション内でABORTが実行された場合、ファンクションは、この呼び出しがトリガーによるものであることを認識せず、区別しないため、ABORTは標準の方法で解釈されます。このような状況(妥当性検査など)でABORTを使用することはお勧めしません。

• I/O操作を実行する「通常の」RDMLファンクションがトリガーの存在を「認識」し、何らかの方法(*LDA、データ・エリアなど)でトリガーと直接「コミュニケーション」を行うような形でトリガーを設計しないことを強くお勧めします。

トリガー「要求」をサポートする場合は、仮想(または実際の)列をテーブル定義に盛り込み、それによって通常の方法でトリガーを発動してください。