Theo kinh nghiệm của tôi, khi các nhà phát triển cố gắng làm cho hệ thống của họ thực sự "năng động", họ thực sự đang cố gắng viết mã cho các vấn đề mà họ chưa nghĩ ra. Đó thường là một con đường xấu để đi. Việc mô-đun bao gồm hai bảng thay vì một bảng có thực sự tốn quá nhiều công sức không?
Trong mọi trường hợp mà tôi đã nhìn thấy khuôn mẫu (hoặc phản mẫu?) Cố gắng tạo ra một bảng "hiện mọi thứ" chung chung thì nó sẽ nằm phẳng trên mặt của nó. RDBMS hoạt động tốt nhất với các khu vực vấn đề được xác định rõ ràng. Nếu mô-đun có nhu cầu lưu giữ lịch sử thì mô-đun phải thêm một bảng lịch sử để đi cùng với bảng đó. Điều này cũng có một lợi thế rất lớn là bạn có thể muốn lưu giữ các loại thông tin khác nhau trong lịch sử tùy thuộc vào bảng hoặc mô-đun mà lịch sử đang được lưu giữ. Nếu bạn có một bảng lịch sử chung sẽ trở nên khó khăn hơn nhiều.
Bây giờ, nếu bạn chỉ muốn bắt người dùng cuối cùng cập nhật hoặc chèn một mục cụ thể (hàng bảng) và mục đó có thể nằm trong nhiều bảng thì bạn có thể sử dụng một mẫu kế thừa trong đó bạn có một bảng cha và nhiều bảng con. Ví dụ:
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)
)