0

この形式のトリガーがあります：

トリガーの作成 TBP701_UPDATE
TBP701の更新後
OLD を OLD_ROW として参照
NEW AS NEW_ROW
行ごとに
モード DB2SQL
TBP702 に挿入 (ID、IRN、イベント、OLDVALUES、NEWVALUES、USER、ENTRYTIME)
値 ( DEFAULT , NEW_ROW . COLUMN1 , 'BUYBACK_ADD' ,
'{"column1":"' CONCAT OLD_ROW . COLUMN1 CONCAT '","column2":"' CONCAT OLD_ROW . COLUMN2 CONCAT '","column3":"' CONCAT OLD_ROW . COLUMN3 CONCAT '"}' ,
'{"column1":"' CONCAT NEW_ROW . COLUMN1 CONCAT '","column2":"' CONCAT NEW_ROW . COLUMN2 CONCAT '","column3":"' CONCAT NEW_ROW . COLUMN3 CONCAT '"}' ,
ユーザー、CURRENT_TIMESTAMP);

tbp701 の古い値と新しい値を json 形式の新しいテーブルに挿入する必要があります。上記のクエリでは、JSON 文字列をハードコーディングしました。しかし、何百ものテーブルにそのようなトリガーを書く必要があります。したがって、次の2つのパラメーターを受け取ることができるSQL関数が必要です

  1. トリガーからの NEW_ROW/OLD_ROW 参照と
  2. テーブル名

トリガーが起動された特定のテーブルと行のすべての列を含むjson文字列を返す必要があります。その後、すべてのトリガーでその関数を再利用できます。

私は、db2 の概念におけるこのような高度な機能に不慣れです。したがって、説明的な回答をいただければ幸いです。

ありがとう。

4

1 に答える 1

0

このデザインを採用することは、ひどい間違いです。

リレーショナル データを JSON 形式で保持するために 2 つ目のスキーマ全体を作成することは、非常に悪夢です。(つまり、これらのトリガーを介して) 一貫性を確保すると、かなりのオーバーヘッドが追加されます。

アプリケーション層でリレーショナル データを解析し、それを JSON 形式に変換しないのはなぜですか?

あるいは、データを XML フォーマットで保管する (および DB2 の pureXML 機能を活用する) ことも検討してください。このトピックに関するdeveloperWorksの記事があります。

于 2013-04-16T19:35:36.833 に答える