Databasetabeller, én tabel, der refererer til flere ikke-relaterede tabeller

Efter min erfaring, når udviklere forsøger at gøre deres system virkelig "dynamisk", forsøger de faktisk at kode for problemer, som de ikke har tænkt på endnu. Det er normalt en dårlig vej at gå. Er det virkelig så meget ekstra arbejde for et modul at inkludere to tabeller i stedet for én?

I alle tilfælde, hvor jeg har set mønsteret (eller anti-mønsteret?) ved at prøve at lave et generisk "gør alt"-bord, er det faldet fladt ned på ansigtet. RDBMS'er fungerer bedst med veldefinerede problemområder. Hvis modulet har behov for at opbevare historik, skal modulet tilføje en historiktabel, der passer til selve tabellen. Dette har også en stor fordel ved, at du hen ad vejen sandsynligvis vil beholde forskellige typer oplysninger i historikken afhængigt af den tabel eller det modul, som historikken opbevares for. Hvis du har en generisk historietabel, bliver det meget vanskeligere.

Hvis du nu blot vil fange den sidste bruger til at opdatere eller indsætte et bestemt element (tabelrække), og det kunne være i flere tabeller, kan du bruge et arvemønster, hvor du har en overordnet tabel og flere underordnede tabeller. For eksempel:

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)
)