トリガー - 推奨事項と禁止事項
推奨事項
· トリガーが関与する複雑なアプリケーションを実装する前に、トリガーを使用して小規模なテスト・ケースを試し、満足できる結果および動作が得られることを確認してください。
· (トリガーが関連付けられた)データ・ディクショナリ内のフィールドのタイプまたは長さを変更したときは、必ず以下を再コンパイルしてください。
· そのフィールドに関連付けられたすべてのトリガー・ファンクション
· そのフィールドを実フィールドまたは仮想フィールドとして含むファイルのすべてのI/Oモジュール
· そのフィールドを含むファイルに対して*DBOPTIMIZE参照を行うすべてのファンクション
· 再コンパイルするオブジェクトのリストは、フィールドの定義の完全なリストを生成することによって簡単に得られます。
· (トリガーが関連付けられた)データベース・ファイルのレイアウトを変更した場合は、必ず以下を再コンパイルしてください。
· そのファイルのI/Oモジュール
· そのファイルに関連付けられたすべてのトリガー・ファンクション
· そのファイルに対して*DBOPTIMIZE参照を行うすべてのファンクション
再コンパイルするオブジェクトのリストは、ファイルの定義の完全なリストを生成することによって簡単に得られます。
禁止事項
· トリガーが関連付けられているファイルに対してI/Oを実行しないでください。直接または間接を問わず、このようなI/Oを実行しようとすると、ファイルのI/Oモジュールが再帰的に呼び出されることがあります。この規則を回避するために、*DBOPTIMIZEを使用しないでください。アクティブなI/Oモジュールのファイル・カーソルが失われたり壊れたりする可能性があります。
· 実フィールドおよび仮想フィールドの数が799個(800番目のフィールド位置は、標準の@@UPIDフィールド用に予約済み)を超えているファイルに対してトリガーを使用しないでください。
· トリガーにより、過度にリソースを消費しないようにしてください。例えば、ファイルからの読み取り後に必ず実行される無条件のトリガーがデータベース・アクセスを3回実行する場合、ベース・ファイルの読み取りに要する時間は少なくとも4倍になります。トリガーは非常に便利な機能ですが、魔法ではありません。多くの処理を実行するようトリガーを設定すると、それに伴ってスループットが低下します。トリガーは、アプリケーション設計者の責任において、その使用によるアプリケーション・スループットへの影響を考慮した上で使用してください。
· トリガー間に依存関係を作成しないでください。例えば、トリガーA (UPDATE前)によってフィールドXの値を設定するとします。トリガーB (同じくUPDATE前)を、最初にトリガーAが実行されている(これによってフィールドXが設定されている)ことを「認識」した上で、トリガーAの後に実行するよう設定することはお勧めしません。これは、トリガー間の「相互依存」の一例で、トリガーの使用方法として適切ではありません。この場合、トリガーA内の、フィールドXに値を設定する処理の後に、トリガーBのロジックを直接挿入してください。
· トリガー・ファンクションからユーザー出口が呼び出されたときにABORTを使用しないでください。トリガー・ファンクション内でABORTが実行されると、I/OモジュールがABORTを中断できるようになり、ファンクションにトリガー・エラー状況を渡します。ただし、トリガーによって呼び出された(ユーザー出口)ファンクション内でABORTが実行された場合、ファンクションは、この呼び出しがトリガーによるものであることを認識せず、区別しないため、ABORTは標準の方法で解釈されます。このような状況(妥当性検査など)でABORTを使用することはお勧めしません。
· I/O操作を実行する「通常の」RDMLファンクションがトリガーの存在を「認識」し、何らかの方法(*LDA、データ・エリアなど)でトリガーと直接「コミュニケーション」を行うような形でトリガーを設計しないことを強くお勧めします。
トリガー「要求」をサポートする場合は、仮想(または実)フィールドをファイル定義に盛り込み、それによって通常の方法でトリガーを発動してください。