2017-05-23 5 views
0

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の継承を使用する方が良いでしょうか、それとも私が考慮していない他のアイデアはありますか?

答えて

0

私はそれが継承または多型を必要としているとは言いません。管理者とスーパー管理者は両方ともユーザーの種類であり、前者が組織に属している点のみが異なります。これは、単一の表とNULL可能な外部キーで表現できます。問題を過度に複雑化する必要はありません。特にserialを主キータイプとして使用している場合、管理者#2をスーパー管理者#2と混同すると、悪いことが起こります。

+0

おそらく例は不完全ですが、組織に属しているのは唯一の違いではなく、大きなものです。また、私はこの例では、null可能な外部キーが悪い考えであるとキャンプにいます。 (知られていない値と値を持たない値の違い)例を親管理テーブルの例で更新し、例のsuper_adminsとregular_adminsのidカラムの変更をカスケードします(これは、 )。 –

関連する問題