Tablas de base de datos, una tabla que hace referencia a varias tablas no relacionadas

En mi experiencia, cuando los desarrolladores intentan hacer que su sistema sea realmente "dinámico", en realidad están tratando de codificar problemas en los que aún no han pensado. Ese suele ser un mal camino a seguir. ¿Realmente es tanto trabajo extra para un módulo incluir dos tablas en lugar de una?

En todos los casos en los que he visto el patrón (¿o el anti-patrón?) de tratar de hacer una mesa genérica "para todo", se ha caído de bruces. Los RDBMS funcionan mejor con áreas problemáticas bien definidas. Si el módulo tiene la necesidad de mantener el historial, entonces el módulo debe agregar una tabla de historial para acompañar a la tabla misma. Esto también tiene una gran ventaja en el sentido de que, en el futuro, es probable que desee mantener diferentes tipos de información en el historial según la tabla o el módulo para el que se mantiene el historial. Si tiene una tabla de historial genérica, eso se vuelve mucho más difícil.

Ahora, si simplemente desea capturar al último usuario para actualizar o insertar un elemento en particular (fila de la tabla) y eso podría estar en varias tablas, entonces podría usar un patrón de herencia donde tiene una tabla principal y varias tablas secundarias. Por ejemplo:

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