PostgreSQLテーブルの行をバージョン管理するためのDklab_rowlogライブラリ
今日のトピック「 バージョン管理とデータ履歴」の続きで、使用する簡単なツールを共有します。
Dklab_rowlogは、データベースの任意のテーブルにレコードのバージョン管理を追加できる、いくつかのPostgreSQLストアドプロシージャのライブラリです。 言い換えれば、テーブルに何が起きても、そこでデータがどのように変更されても（追加/削除）、これは特別なログプレートに反映されます。
利点：
- バージョン管理は、1つのSQLコマンドを使用して1分ですべてのテーブルに追加されます。
- 保存する列と保存しない列（スペースを節約する列）を指定できます。 この場合、指定された列の少なくとも1つが変更された場合にのみ、ログエントリが追加されます。
- 「変更の作成者のID」として解釈される列を指定できます。
- 列が変更されたかどうかに関係なく、どのような場合でもログに記録される列を指定できます。
使用例
このようなプレートの変更を記録する必要があるとします：
CREATE TABLE test_src1 （
id bigint NOT NULL 、
変化するキャラクター（ 20 ） 、
b文字変化（ 20 ） 、
c文字可変（ 20 ） 、
modified_by bigint NOT NULL
） ;
例1： 「a」列と「c」列の変更のみを追跡します。 これらのフィールドの1つが変更されるとすぐに、これに関するレコードがpublic.rowlogに追加されます。
CREATE TRIGGER t_rowlog
各行のtest_src1での挿入、 削除、 または 更新後
PROCEDURE rowlogを実行します。 t_rowlog_aiud （ 'diff => a' 、 'diff => c' 、 'rowlog => public.rowlog' ） ;
例2：テーブルの行を変更する場合、常に行ログにエントリを追加しますが、列「a」と「b」のみを保存します。 ところで、パラメータ 'rowlog => xxx'は省略できます。 デフォルトでは、CURRENT_SCHEMA.rowlogと同じです。
CREATE TRIGGER t_rowlog
各行のtest_src1での挿入、 削除、 または 更新後
PROCEDURE rowlogを実行します。 t_rowlog_aiud （ 'always => a' 、 'always => b' ） ;
例3：各ログエントリに、「変更の作成者」のIDを保存します。 また、テーブルの主キーの名前を明示的に指定することもできます（デフォルトは「id」です）。
CREATE TRIGGER t_rowlog
各行のtest_src1での挿入、 削除、 または 更新後
PROCEDURE rowlogを実行します。 t_rowlog_aiud （ 'always => a' 、 'author => modified_by' 、 'pk => id' ） ;
ログテーブル構造
構造はおよそ次のとおりです。
CREATE TABLE rowlog （
-行バージョンの主キー。
id BIGSERIAL NOT NULL 、
-このバージョン作成のタイムスタンプ。
タイムスタンプがデフォルトのタイムスタンプをタイムスタンプにスタンプ（ ） NOT NULL 、
-ソース行を変更したのは誰ですか？ BIGINTだけでなく、任意のタイプを指定できます。
著者bigint 、
-変更された行のテーブルOID。
rel regclass NOT NULL 、
-前の行の列。
data_old hstore 。 hstore NOT NULL 、
-結果の行列。
data_new hstore 。 hstore NOT NULL 、
-操作の変更（INSERT / UPDATE / DELETE）。
操作enum_tg_op NOT NULL 、
-ソーステーブルの行の主キー。
pk bigint 、
制約 "rowlog_pkey" 主 キー （ "id" ）
） ;
他のフィールドを追加したり、インデックスをマウントしたりできます。 異なるテーブルのレコードを同じログテーブルに保存できます（この場合、バージョン管理の追加は1つのCREATE TRIGGERコマンドになるため、これが最も便利です）。
制限事項
使用する際に考慮すべき2つの事項があります。
- ライブラリは、超高負荷向けに設計されていません。 内部にはいくつかのEXECUTE SQLがあります。 ただし、1秒あたり数千回の挿入に簡単に耐えることができます。
- ソーステーブルに新しいフィールドをすばやく追加できるため、変更されたデータをhstoreに保存すると便利ですが、欠点があります：ソーステーブルが時間の経過とともに構造的に大幅に変更されると（たとえば、フィールドが削除されたり名前が変更されたりすると）、古いバージョンの古いバージョンがhstoreに残ります構造。
All Articles