次に、このデータベースの監査の例を考えてみましょう。 私たちが興味を持っているのは、誰が、いつ、何をテーブルでしたかです。 どのレコード(「オブジェクト」を読む)が追加され、どのレコードが削除され、どのレコードが変更されたので、将来「誤解」が発生しなくなります。
最初に行うことは、機能を持つ既存のテーブルのコピーを作成し、それらを他の名前と呼びます。 テーブル自体ではなく、その構造。 例:
CREATE TABLE audit_building AS SELECT * FROM building1;
次に、監査用のテーブルに新しい列を追加します。
ALTER TABLE audit_building ADD COLUMN operation char(1); -- , ALTER TABLE audit_building ADD COLUMN stamp timestamp; -- ALTER TABLE audit_building ADD COLUMN userid text; --
その後、すべての変更を追跡するトリガーを作成します。
CREATE OR REPLACE FUNCTION process_emp_audit() RETURNS TRIGGER AS $audit_building$ BEGIN IF (TG_OP = 'DELETE') THEN INSERT INTO audit_building SELECT 'D', now(), user, OLD.*; RETURN OLD; ELSIF (TG_OP = 'UPDATE') THEN INSERT INTO audit_building SELECT 'U', now(), user, NEW.*; RETURN NEW; ELSIF (TG_OP = 'INSERT') THEN INSERT INTO audit_building SELECT 'I', now(), user, NEW.*; RETURN NEW; END IF; RETURN NULL; END; $audit_building$ LANGUAGE plpgsql; CREATE TRIGGER audit_building AFTER INSERT OR UPDATE OR DELETE ON building1 FOR EACH ROW EXECUTE PROCEDURE process_emp_audit();
ユーザーが監査テーブルにエントリを作成する権限を割り当てることのみが残ります。
GRANT SELECT ON audit_building TO user2;
そして確認できます!
レイヤーを操作した後に何が起こったのかを次に示します。
ここでは、user2が1つのオブジェクトを3つの新しいオブジェクト(I)を作成し、変更(U)および削除(D)していることがわかります。 ユーザーがルールのどのオブジェクトであるかを確認するには、マップレイヤーを含むテーブルの列が必要です。 これには一意の識別子フィールドを使用できます。
以上です! これで、テーブルに加えられたすべての変更を制御できるようになりました。