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

16

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 souhaite modifier le message. Je veux garder une trace de son état avant le changement et après le changement.

Quelle serait la meilleure approche pour mettre en place 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 veux également créer une AUDIT TRAILtable history ( ) qui contient l' idétat précédent, idle nouvel état, à quelle table ces identifiants se rapportent-ils?

mysql database-design audit

— Schwarz
source

1

Vous pouvez utiliser des déclencheurs de base de données pour créer une table d'audit .

— Kin Shah

5

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.

— Hector
source

quelle est la meilleure façon d'appliquer la «solution n ° 2: table de traçage des données dédiée» pour une application OLTP.

— AA.SC

L'entreprise pour laquelle je travaille utilise actuellement plusieurs schémas, un spécifiquement pour la piste d'audit. La table d'audit est vraiment une conception assez simple lors de l'utilisation de la solution n ° 2 (qui est exactement ce que nous utilisons ici au travail). Décomposer les différentes tâches (tableau d'inventaire mis à jour, informations client mises à jour ou supprimées, crédits fournis au client, etc.) et construire le tableau d'audit en fonction des actions courantes dont les utilisateurs sont capables. Est-ce que cela répond à votre question concernant l'application de la solution 2 à votre base de données, sinon veuillez clarifier. Merci!

— Hector

En fait, nous vérifions déjà les données avec la première approche à l'aide des tables d'audit, mais les données d'audit deviennent si énormes et nous voulons maintenant convertir notre approche en capturant simplement les données dans des colonnes modifiées. Ma question est de savoir comment puis-je réaliser cette approche? quelle est la meilleure façon de suivre quelle colonne du tableau est modifiée? .. si une table comporte plus de 20 colonnes, l'une d'elles est avec DataType Text.

— AA.SC

10

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.

Voici les diapositives d'une présentation que j'ai faite à quelques reprises lors de salons techniques. Il explique comment faire tout ce qui précède. Et voici 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.

— TommCatt
source

1

Très beaux points! Cependant, je ne comprends pas très bien This means no flag or other indicator showing which is the current version and which are "history.", si aucun indicateur ou indicateur, comment nous différencions la version actuelle de la version historique? Surtout en fonction de votre troisième point que vous suggérez qu'ils devraient être dans le même tableau.

— GMsoF

La présentation montre un exemple de conception, y compris la requête pour lire les données actuelles et / ou passées des tables. S'il semble suffisamment intéressant pour approfondir, le document contient beaucoup plus de détails.

— TommCatt