データベーステーブル、複数の無関係なテーブルを参照する1つのテーブル

私の経験では、開発者がシステムを本当に「動的」にしようとすると、実際にはまだ考えていない問題をコーディングしようとしています。これは通常、悪い道です。モジュールに1つではなく2つのテーブルを含めるのは本当に大変な作業ですか？

一般的な「すべてを実行する」テーブルを作成しようとするパターン（またはアンチパターン？）を目にしたすべての場合で、テーブルは平らになります。 RDBMSは、明確に定義された問題領域で最適に機能します。モジュールが履歴を保持する必要がある場合、モジュールはテーブル自体に合わせて履歴テーブルを追加する必要があります。これには、履歴が保持されているテーブルまたはモジュールに応じて、さまざまな種類の情報を履歴に保持する可能性が高いという大きな利点もあります。はるかに困難になる一般的な履歴テーブルがある場合。

ここで、特定のアイテム（テーブル行）を更新または挿入する最後のユーザーを単純にキャプチャし、それが複数のテーブルに存在する可能性がある場合は、親テーブルと複数の子テーブルがある継承パターンを使用できます。例：

CREATE TABLE Audited_Items
(
    id    INT    NOT NULL    IDENTITY,
    CONSTRAINT PK_Audited_Items PRIMARY KEY CLUSTERED (id)
)
CREATE TABLE Articles
(
    id    INT            NOT NULL,
    [Article specific columns]
    CONSTRAINT PK_Articles PRIMARY KEY CLUSTERED (id),
    CONSTRAINT FK_Articles_Audited_Items FOREIGN KEY (id) REFERENCES Audited_Items (id)
)
CREATE TABLE Media
(
    id    INT            NOT NULL,
    [Media specific columns]
    CONSTRAINT PK_Media PRIMARY KEY CLUSTERED (id),
    CONSTRAINT FK_Media_Audited_Items FOREIGN KEY (id) REFERENCES Audited_Items (id)
)
CREATE TABLE Audit_Trail
(
    audited_item_id    INT         NOT NULL,
    audit_datetime     DATETIME    NOT NULL,
    user_id            INT         NOT NULL,
    [audit columns]
    CONSTRAINT PK_Audit_Trail PRIMARY KEY CLUSTERED (audited_item_id, audit_datetime),
    CONSTRAINT FK_Audit_Trail_Audited_Items FOREIGN KEY (audited_item_id) REFERENCES Audited_Items (id)
)