Според моя опит, когато разработчиците се опитват да направят системата си наистина "динамична", те всъщност се опитват да кодират проблеми, за които все още не са се сетили. Обикновено това е лош път. Наистина ли е толкова много допълнителна работа за модул да включва две таблици вместо една?
Във всеки случай, в който съм виждал модела (или анти-модел?) на опит за създаване на обща таблица за „прави всичко“, тя е паднала по лицето си. 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)
)
