D'après mon expérience, lorsque les développeurs essaient de rendre leur système vraiment "dynamique", ils essaient en fait de coder pour des problèmes auxquels ils n'ont pas encore pensé. C'est généralement un mauvais chemin à prendre. Est-ce vraiment tellement de travail supplémentaire pour un module d'inclure deux tables au lieu d'une ?
Dans tous les cas où j'ai vu le modèle (ou l'anti-modèle ?) D'essayer de créer un tableau générique "fait tout", il est tombé à plat sur son visage. Les SGBDR fonctionnent mieux avec des problèmes bien définis. Si le module a besoin de conserver l'historique, le module doit ajouter une table d'historique pour aller avec la table elle-même. Cela présente également un énorme avantage dans la mesure où vous souhaiterez probablement conserver différents types d'informations dans l'historique en fonction de la table ou du module pour lequel l'historique est conservé. Si vous avez une table d'historique générique, cela devient beaucoup plus difficile.
Maintenant, si vous voulez simplement capturer le dernier utilisateur à mettre à jour ou insérer un élément particulier (ligne de table) et qui pourrait se trouver dans plusieurs tables, vous pouvez utiliser un modèle d'héritage où vous avez une table parent et plusieurs tables enfants. Par exemple :
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)
)
