Z mojego doświadczenia wynika, że gdy programiści próbują uczynić swój system naprawdę „dynamicznym”, w rzeczywistości próbują kodować problemy, o których jeszcze nie pomyśleli. To zwykle zła droga. Czy to naprawdę taka dodatkowa praca, aby moduł zawierał dwie tabele zamiast jednej?
W każdym przypadku, w którym widziałem wzór (lub anty-wzorzec?) próbując zrobić ogólny stół „zadaje wszystko”, spadł on płasko na twarz. Systemy RDBMS działają najlepiej w dobrze zdefiniowanych obszarach problemowych. Jeśli moduł ma potrzebę przechowywania historii, moduł powinien dodać tabelę historii, która będzie pasować do samej tabeli. Ma to również ogromną zaletę, ponieważ prawdopodobnie będziesz chciał przechowywać różne rodzaje informacji w historii w zależności od tabeli lub modułu, dla którego jest przechowywana historia. Jeśli masz ogólną tabelę historii, która staje się znacznie trudniejsza.
Teraz, jeśli chcesz po prostu przechwycić ostatniego użytkownika, który aktualizuje lub wstawia określony element (wiersz tabeli), który może znajdować się w wielu tabelach, możesz użyć wzorca dziedziczenia, w którym masz tabelę nadrzędną i wiele tabel podrzędnych. Na przykład:
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)
)
