Meiner Erfahrung nach versuchen Entwickler, wenn sie versuchen, ihr System wirklich "dynamisch" zu machen, tatsächlich, Probleme zu codieren, an die sie noch nicht gedacht haben. Das ist normalerweise ein schlechter Weg. Ist es wirklich so viel Mehrarbeit für ein Modul, zwei Tabellen statt einer zu enthalten?
In jedem Fall, in dem ich das Muster (oder Anti-Muster?) des Versuchs gesehen habe, einen generischen „macht alles“-Tisch zu erstellen, ist er flach auf die Nase gefallen. RDBMS funktionieren am besten mit genau definierten Problembereichen. Wenn das Modul den Verlauf speichern muss, sollte das Modul eine Verlaufstabelle hinzufügen, die zu der Tabelle selbst gehört. Dies hat auch insofern einen großen Vorteil, als Sie später wahrscheinlich unterschiedliche Arten von Informationen im Verlauf behalten möchten, je nachdem, für welche Tabelle oder welches Modul der Verlauf gespeichert wird. Wenn Sie eine generische Verlaufstabelle haben, wird das viel schwieriger.
Wenn Sie nun einfach den letzten Benutzer erfassen möchten, der ein bestimmtes Element (Tabellenzeile) aktualisiert oder eingefügt hat, und das sich in mehreren Tabellen befinden könnte, könnten Sie ein Vererbungsmuster verwenden, bei dem Sie eine übergeordnete Tabelle und mehrere untergeordnete Tabellen haben. Zum Beispiel:
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)
)
