SQL トリガーのモード (DB2SQL/DB2ROW)

SQL トリガーには DB2SQL と DB2ROW といったトリガーの実行のモードがあります。

以前触れましたが、「DB2ROW の場合は各行毎に実際に実行され、DB2SQLの場合は各行毎に計算は行われるが実際に実行されるのは一番最後というかたちになります。DB2SQL は通常の UDBの場合に実行されるやり方ですが、潜在的に各行は2回アクセスされることになりあまり効率はよくないかもしれません」ということになります。

その違いがでてくるケースについてテストしながら、具体的にどういうことかを見ていきましょう。

また、注意なのですが、SQLの世界ではだいたいユーザーの名前がテーブルの名前のクオリファイアとして使用され、それは iSeriesの世界では「ライブラリー」が指定される位置になっています。
ですので必ずライブラリーと同じ名前のユーザーを作成して、そのユーザーでログインして作業してください。「ライブラリー」=「スキーマ」=「ユーザー」という意識を持って作業するようにしてください。
以下の一連の作業も QEOL というユーザーを作成し、そのユーザープロフィールでログインして行っています。

今度は INSERT で起動するトリガーを例にとって見ていきます。


事前準備 (トリガーのテスト用のテーブルの準備)

トリガーが起動されるもとになるテーブルを作成します。
特に内容はなんでもいいのですが "InsertTest" としました。

内容はやっぱりなんでもいいのですが、まあ "ID" と "Name" というカラムを作りました。

わざわざ作ることもないかもしれませんが、他のテーブルからいっぺんに行が挿入される状態をテストするために、その挿入元としてまったく同じ構造のテーブルを作成しました。
名前だけ "InsertTestFrom" にかえただけで同じカラムを持つテーブルです。

"InsertTest" と同様にカラムを定義します。

オペレーション・ナビゲーターを使って "InsertTestFrom" の方にデータを入れます。
「行」の「挿入」を使ってデータを入れていくことができます。

「ファイル」-「保管」で入力したデータを保管します。

トリガーの結果をモニターするためのテーブルを作成します。
内容は前に使ったカウントのロジックを使いまわして、挿入されつつあるテーブルの行数を調べます。

カウントを保管するカラムを定義します。

こちらはモードをかえたトリガーのモニター用のテーブルです。

内容はまったく同じにしています。

これで事前準備は完了です。


トリガーの定義

トリガーを起動させるテーブルのプロパティを選んで表示します。

「SQL トリガーの追加」ボタンを押すと、トリガーの定義画面になります。

まず最初に "InsertTest1" という名でトリガーを作ります。
イベントは「挿入」ですね。

トリガーの起動は INSERT文が実行された後です。(AFTER TRIGGER)

タイミングは「行ごと」(= FOR EACH ROW) で、こちらのトリガーは「DB2ROW」にしておきます。

挿入されたテーブル (= トリガーの起動元であるテーブル) の件数をカウントし、モニターするテーブルに保管する、というロジックになっています。

対比用に "InsertTest2" という、モードと結果を保管するテーブル以外はまったく同じトリガーを作成します。

イベントは「挿入」です。

"InsertTest1" とまったく同じように定義し、モードだけを「DB2SQL」にします。

カウントした結果を保管するテーブルの指定以外はまったく同じSQL文を指定します。

双方の定義を終えると下記の画面になります。「OK」ボタンを押して、トリガーのコンパイルを行います。


テストの実行

かねてから準備しておいたデータの挿入元テーブルから、データの挿入をトリガーの起動元のテーブルに対して行います。

結果のペインを見ると、ちゃんと 6行挿入されています。

では、それぞれのトリガーの結果を見ていきましょう。

まず、「DB2ROW」のモードのトリガーです。
各行ごとに実行されているので、行が挿入されるごとに行数が増えていっています。

こちらが「DB2SQL」モードの結果です。
各行ごとの実行なので、6行ぶん結果が入っていますが、すべての行が挿入され終わって実行されるため、結果はすべて挿入され終わったテーブルの行数である 「6」 になっています。
(ちなみに FOR EACH STATEMENT で実行すれば1行のみになりますね。こちらもご参照ください)

[Top Pageに戻る]

Ads by TOK2