Podle mých zkušeností, když se vývojáři snaží udělat svůj systém opravdu „dynamickým“, ve skutečnosti se snaží kódovat problémy, které je dosud nenapadly. To je obvykle špatná cesta. Je opravdu tolik práce navíc, aby modul obsahoval dvě tabulky místo jedné?
V každém případě, kdy jsem viděl vzorec (nebo anti-vzor?) pokusu vytvořit generickou tabulku „dělá všechno“, mi padl na hlavu. RDBMS fungují nejlépe s dobře definovanými problémovými oblastmi. Pokud modul potřebuje uchovávat historii, pak by měl modul přidat tabulku historie, která půjde s tabulkou samotnou. To má také obrovskou výhodu v tom, že budete pravděpodobně chtít v historii uchovávat různé typy informací v závislosti na tabulce nebo modulu, pro který je historie uchovávána. Pokud máte obecnou tabulku historie, bude to mnohem obtížnější.
Nyní, pokud chcete jednoduše zachytit posledního uživatele, který aktualizoval nebo vložil určitou položku (řádek tabulky) a která by mohla být ve více tabulkách, můžete použít vzor dědičnosti, kde máte nadřazenou tabulku a více podřízených tabulek. Například:
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)
)