web-dev-qa-db-fra.com

La meilleure façon de concevoir une base de données et une table pour conserver des enregistrements des modifications?

J'ai besoin de configurer une fonction d'historique sur un projet pour garder une trace des modifications antérieures.

Disons que j'ai deux tables en ce moment:

NOTES TABLE (id, userid, submissionid, message)

SUBMISSIONS TABLE (id, name, userid, filepath)

Exemple: J'ai une ligne dans les notes et l'utilisateur veut changer le message. Je veux garder une trace de son état avant le changement et après le changement.

Quelle serait la meilleure approche pour configurer une colonne dans chacun de ces tableaux qui dira si un élément est "ancien". 0 si actif OU 1 s'il est supprimé/invisible.

Je souhaite également créer un historique (AUDIT TRAIL) table qui contient le id de l'état précédent, le id du nouvel état, à quelle table ces identifiants se rapportent?

mysqldatabase-designaudit
16
Schwarz

Veuillez consulter

http://www.codeproject.com/Articles/105768/Audit-Trail-Tracing-Data-Changes-in-Database

C'est une très bonne lecture sur les approches pour créer une piste d'audit dans la conception de votre base de données. Les pistes d'audit sont nécessaires à la mise en place d'une base de données. Vous devriez toujours pouvoir voir les actions des utilisateurs de la base de données au sein du système.

Nous pouvons suivre les lignes qui ont été modifiées dans notre système PTA (point dans le temps) en ajoutant des colonnes PTA standard (point dans le temps) à toutes les tables d'intérêt PTA.

Je suggère ce qui suit:

DateCreated – the actual date on which the given row was inserted.
DateEffective – the date on which the given row became effective.
DateEnd – the date on which the given row ceased to be effective.
DateReplaced – the date on which the given row was replaced by another row.
OperatorCode – the unique identifier of the person (or system) that created the row.
5
Hector

Lors de la conception de capacités de contrôle de version dans vos données, il existe plusieurs exigences minimales (je pense):

  • Chaque version des données doit être autonome et indépendante des autres versions. Cela signifie aucun indicateur ou autre indicateur indiquant quelle est la version actuelle et qui sont "historique". Cela signifie également que la mise à jour de l'entité signifie l'insertion d'une nouvelle version uniquement - aucune mise à jour des versions précédentes n'est nécessaire.
  • Évitez ce que j'appelle la dépendance à l'échelle des lignes. C'est là qu'un champ (End_Date) d'une ligne doit rester synchronisé avec un autre champ (Start_Date) d'une ligne différente. Cela rend le travail avec les données plus difficile et constitue une excellente source d'anomalies.
  • La version actuelle et toutes les versions antérieures doivent être dans le même tableau. Cela permet d'utiliser la même requête pour visualiser les données passées "à partir de" une date particulière et pour visualiser les données actuelles.
  • Les clés étrangères des données qui ont été versionnées devraient fonctionner de la même manière que les données normales (non versionnées).
  • La conception doit être si simple ou universellement comprise que la courbe d'apprentissage pour les nouveaux développeurs est minimisée.

Ici sont les diapositives d'une présentation que j'ai faite plusieurs fois lors de salons techniques. Il explique comment faire tout ce qui précède. Et ici est un document qui va plus en détail. Je dois m'excuser pour le document - c'est un travail en cours et toutes les sections ne sont pas terminées. Mais il devrait vous donner toutes les informations nécessaires pour implémenter quoi que ce soit, du simple versionnage à l'accès bi-temporel complet.

10
TommCatt