Dalam pengalaman saya, ketika pengembang mencoba membuat sistem mereka benar-benar "dinamis", mereka sebenarnya mencoba membuat kode untuk masalah yang belum mereka pikirkan. Itu biasanya jalan yang buruk untuk diambil. Apakah benar-benar banyak pekerjaan ekstra untuk sebuah modul untuk memasukkan dua tabel, bukan satu?
Dalam setiap kasus di mana saya telah melihat pola (atau anti-pola?) dari mencoba membuat tabel "melakukan segalanya" generik, itu jatuh rata di wajahnya. RDBMS bekerja paling baik dengan area masalah yang terdefinisi dengan baik. Jika modul memiliki kebutuhan untuk menyimpan riwayat maka modul harus menambahkan tabel riwayat agar sesuai dengan tabel itu sendiri. Ini juga memiliki keuntungan besar karena kemungkinan besar Anda ingin menyimpan berbagai jenis informasi dalam riwayat tergantung pada tabel atau modul tempat riwayat disimpan. Jika Anda memiliki tabel riwayat umum, itu menjadi jauh lebih sulit.
Sekarang, jika Anda hanya ingin menangkap pengguna terakhir untuk memperbarui atau menyisipkan item tertentu (baris tabel) dan itu bisa dalam beberapa tabel, maka Anda bisa menggunakan pola pewarisan di mana Anda memiliki tabel induk dan beberapa tabel anak. Misalnya:
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)
)
