【AS400】テンポラル・テーブル検証 - タイガー！タイガー！じれったいぞー！（SE編）

AS400、つまりは「DB2 for i」の新機能であります「テンポラル・テーブル」を試してみたので、まとめておきます。

当機能は、V7R03から利用可能とのこと。

テンポラル・テーブルとは？

そもそも、テンポラル・テーブルとは何か？
ベルさんのサイトに詳しく書かれておりました。

www.e-bellnet.com

勝手に要約しますと、DBの「タイムマシーン」機能といったところでしょうか。
この機能により、タイムマシーンに乗って、1ヵ月前の受注残明細を調べる、1年前の在庫状況を調べる、なんてことがSQLでできるというわけです。

検証作業

下記のIBMのサイトを丸写しして、実際に操作してみました。

https://www.ibm.com/support/knowledgecenter/ja/ssw_ibm_i_73/sqlp/rbafycrttemporaltable.htm

まずは、テーブル作成。

STRSQL

CREATE OR REPLACE TABLE TIGERDB.DEPARTMENT  
    (DEPTNO    CHAR(3)       NOT NULL, 
     DEPTNAME  VARCHAR(36)   NOT NULL, 
     MGRNO     CHAR(6),   
     ADMRDEPT  CHAR(3)       NOT NULL,   
     LOCATION  CHAR(16), 
     START_TS  TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW BEGIN,
     END_TS    TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW END,
     TS_ID     TIMESTAMP(12) GENERATED ALWAYS AS TRANSACTION START ID,
     PERIOD SYSTEM_TIME (START_TS, END_TS),    
     PRIMARY KEY (DEPTNO))

-- TIGERDB にテーブル DEPARTMENT が作成されましたが，ジャーナル処理されていません。

次に「テンポラル表」を作成。

CREATE TABLE TIGERDB.DEPARTMENT_HIST   
    LIKE TIGERDB.DEPARTMENT

-- TIGERDB にテーブル DEPARTMENT_HIST が作成されましたが，ジャーナル処理されていません。

最後にテーブルとテンポラル表の紐づけ作業。
１つのテーブルに対して、１つのテンポラル表となるようです。

ALTER TABLE TIGERDB.DEPARTMENT                                
    ADD VERSIONING USE HISTORY TABLE
    TIGERDB.DEPARTMENT_HIST

-- TIGERDB のテーブル DEPARTMENT に対する ALTER が完了しました。

１レコードを追加します。

INSERT INTO TIGERDB/DEPARTMENT (DEPTNO, DEPTNAME, MGRNO, ADMRDEPT) 
VALUES('01', ' 営業１課 ', '123', 'JPN')                     

-- TIGERDB の DEPARTMENT に 1 行が挿入された。

間隔（５分程度）をあけて、もう１行追加。

INSERT INTO TIGERDB/DEPARTMENT (DEPTNO, DEPTNAME, MGRNO, ADMRDEPT) 
VALUES('02', ' 営業２課 ', '456', 'JPN')                     

-- TIGERDB の DEPARTMENT に 1 行が挿入された。

まずは、普通にSELECTしますと･･･。

SELECT * FROM TIGERDB/DEPARTMENT 

-- DEPTNO DEPTNAME MGRNO ADMRDEPT LOCATION　START_TS　　　　　　　　　　　　　　　END_TS　　　　　　　　　　　　　TS_ID
--  01　　営業１課　123　　JPN　　　-　　　　2018-12-21-18.25.03.971940000244   9999-12-30-00.00.00.000000000000   -
--  02　　営業２課　456　　JPN　　　-　　　　2018-12-21-18.30.24.786911000244   9999-12-30-00.00.00.000000000000   -

２件とも抽出されます。当然です。

次に、６ヵ月前にワープ！

SELECT * FROM TIGERDB/DEPARTMENT FOR SYSTEM_TIME AS OF CURRENT TIMESTAMP - 6 MONTHS

-- データなし

データは抽出されませんでした。

では、５分前ではどうか？

SELECT * FROM TIGERDB/DEPARTMENT FOR SYSTEM_TIME AS OF CURRENT TIMESTAMP - 5 MINUTES 

-- DEPTNO DEPTNAME MGRNO ADMRDEPT LOCATION　START_TS　　　　　　　　　　　　　　　END_TS　　　　　　　　　　　　　TS_ID
--  01　　営業１課　123　　JPN　　　-　　　　2018-12-21-18.25.03.971940000244   9999-12-30-00.00.00.000000000000   -

１件だけ抽出されました。お！　素晴らしい！！

ちなみに１分前ではどうでしょう？　上記操作で１分くらい経過したはず。

SELECT * FROM TIGERDB/DEPARTMENT FOR SYSTEM_TIME AS OF CURRENT TIMESTAMP - 1 MINUTES  

-- DEPTNO DEPTNAME MGRNO ADMRDEPT LOCATION　START_TS　　　　　　　　　　　　　　　END_TS　　　　　　　　　　　　　TS_ID
--  01　　営業１課　123　　JPN　　　-　　　　2018-12-21-18.25.03.971940000244   9999-12-30-00.00.00.000000000000   -
--  02　　営業２課　456　　JPN　　　-　　　　2018-12-21-18.30.24.786911000244   9999-12-30-00.00.00.000000000000   -

無事に２件とも表示されました！

所感

ベル・データさんのWebページの記事の最後に、テンポラル・テーブルを取り入れるための弊害が３つ書かれておりました。

運用中のIBMi（AS400）に取り入れるための壁
1. 参照する一連のRPGなどのPGMも再コンパイルが必要
2. 履歴表のデータ容量管理が必要
3. スキーマ変更は、DDSではなくSQLのALTER TABLEコマンドを利用する（AS400技術者は不慣）

AS400のテーブル作成方法として、旧来型のDDSで記述し、CRTPFする方法と、SQLのDDLで作成する２つがありますが、昔からAS400を活用している企業では、DDSで書かれたテーブルが多く存在すると思われます。

つまりは、上記の１が最大のネックとなりそうです。
既存のRPGアプリをリ・コンパイルする必要が出てくる。
１０~２０本単位であれば、トライすべきでしょうが、何１００、何１０００レベルになると、それなりの工数が必要です。

さらには、データがどの程度増えるか、いまいちわかっておらず、大量のトランザクションが発生するテーブルでは、HDDを圧迫していまうというリスクが絶えず付きまといそうです。

結論が最後になってしまいましたが、現システム環境では、テンポラル・テーブルの利用は見送りたいと思います。

当面は、テーブルごとにログを書き出すことは継続する必要がありそうですね。

しかしながら、次回DBリファクタリング時には、導入するかの検討は忘れずにしたいです。
もし導入すれば、照会アプリの抽出条件に、時間軸（ex：1ヵ月前、１年前）を加えることができるわけですから。
ん？　それって必要か？　BIツールで十分かも。

まあ、良しとしましょう。