PostgreSQLで監査可能なユーザIDの種類があるAuditテーブル設計を実装しようとしています。複数の "ユーザタイプ"を持つPostgreSQL監査テーブルデザイン
はのは、私は(ない)管理者(組織に属している)、およびテーブルsuperadminsという名前のテーブルがあるとしましょう。今、監査テーブル
CREATE TABLE example.organizations (
id SERIAL UNIQUE,
company_name varchar(50) NOT NULL UNIQUE,
phone varchar(20) NOT NULL check (phone ~ '^[0-9]+$')
);
と潜在的な管理設計の例
CREATE TABLE example.admins (
id serial primary_key,
admin_type varchar not null,
#... shared data
check constraint admin_type in ("super_admins", "regular_admins")
);
CREATE TABLE example.regular_admins (
id integer primary key,
admin_type varchar not null default "regular_admins"
organization_id integer references example.organizations(id),
#... other regular admin fields
foreign key (id, admin_type) references example.admins (id, admin_type),
check constraint admin_type = "regular_admins"
);
CREATE TABLE example.super_admins (
id integer primary key,
admin_type varchar not null default "super_admins"
#... other super admin fields
foreign key (id, admin_type) references example.admins (id, admin_type),
check constraint admin_type = "super_admins"
);
CREATE TABLE audit.organizations (
audit_timestamp timestamp not null default now(),
operation text,
admin_id integer primary key,
before jsonb,
after jsonb,
);
これは、いくつかのレベルでの継承やポリモーフィズムのために呼び出しますが、私はどの程度興味それを設計する。私は、PostgreSQLの継承機能を使っても必ずしも良いとは言えないと聞いてきましたが、このユースケースに合うように探しています。
監査テーブルを更新するトリガ内の1つの管理者IDを参照できるようにする必要があります。複数のクエリを使用せずに監査テーブルから選択するときに管理者情報を取得できるのは良いことです。
PostgreSQLの継承を使用する方が良いでしょうか、それとも私が考慮していない他のアイデアはありますか?
おそらく例は不完全ですが、組織に属しているのは唯一の違いではなく、大きなものです。また、私はこの例では、null可能な外部キーが悪い考えであるとキャンプにいます。 (知られていない値と値を持たない値の違い)例を親管理テーブルの例で更新し、例のsuper_adminsとregular_adminsのidカラムの変更をカスケードします(これは、 )。 –