Comment contrôler la version d'un enregistrement dans une base de données

je pense que vous êtes à la recherche de versioning le contenu des enregistrements de base de données (comme le fait StackOverflow quand quelqu'un édite une question/réponse). Un bon point de départ pourrait être la recherche d'un modèle de base de données qui utilise le suivi révision .

le meilleur exemple qui vient à l'esprit est MediaWiki, le moteur de Wikipedia. Comparer le diagramme de la base de données ici , en particulier le table de révision .

selon les technologies que vous utilisez, vous devrez trouver de bons algorithmes de diff/Fusion.

Vérifier cette question si c'est pour .NET.

dans le monde BI, vous pouvez accomplir ceci en ajoutant un startDate et endDate à la table que vous voulez version. Lorsque vous insérez le premier enregistrement dans la table, la date start est peuplée, mais la date end est nulle. Lorsque vous insérez le second enregistrement, vous mettez aussi à jour la date de fin du premier enregistrement avec la date de début du second enregistrement.

lorsque vous voulez voir l'enregistrement en cours, vous sélectionnez celui où endDate est null.

C'est parfois appelé un type 2 lentement changer la Dimension . Voir aussi TupleVersioning "151960920

mise à niveau en SQL 2008.

essayez D'utiliser SQL Change Tracking, en SQL 2008. Au lieu de l'horodatage et des hacks de colonnes de pierre tombale, vous pouvez utiliser cette nouvelle fonctionnalité pour suivre les changements sur les données dans votre base de données.

MSDN SQL 2008 Change Tracking

voulait juste ajouter qu'une bonne solution à ce problème est d'utiliser une base de données temporelle . De nombreux fournisseurs de bases de données offrent cette fonctionnalité soit hors de la boîte ou via une extension. J'ai utilisé avec succès la table temporelle extension avec PostgreSQL mais d'autres l'ont aussi. Chaque fois que vous mettez à jour un enregistrement dans la base de données, la base de données tient sur la version précédente de cet enregistrement aussi.

deux options:

1. ont une table d'histoire - insérez les anciennes données dans cette table d'Histoire chaque fois que l'original est mis à jour.
2. tableau de vérification-stocker les valeurs avant et après - juste pour les colonnes modifiées dans un tableau de vérification avec d'autres informations comme qui a mis à jour et quand.

vous ne dites pas quelle base de données, et je ne le vois pas dans les étiquettes postales. Si C'est pour Oracle, je peux vous recommander l'approche qui est intégrée dans Designer: utilisez tables de journal . Si c'est pour une autre base de données, je recommande la même chose...

la façon dont il fonctionne, au cas où vous voulez le répliquer dans un autre DB, ou peut-être si vous voulez juste le comprendre, est que pour une table il y a une table d'ombre créée aussi, juste une normale table de la base de données, avec les mêmes spécifications de champ, plus quelques champs supplémentaires: comme quelle action a été prise en dernier (chaîne, valeurs typiques "INS" pour insert, "UPD" pour update et "DEL" pour delete), datetime pour quand l'action a eu lieu, et ID de l'utilisateur pour qui l'a fait.

par des déclencheurs, chaque action à n'importe quelle ligne dans le tableau insère une nouvelle ligne dans la table de journal avec les nouvelles valeurs, quelle action a été prise, quand, et par quel utilisateur. Vous ne supprimez jamais aucune ligne (au moins pas pour les quelques derniers mois). Oui, il va grossir, facilement des millions de lignes, mais vous pouvez facilement suivre la valeur pour n'importe quel record à n'importe quel point dans le temps depuis le début de la journalisation ou les vieilles lignes de journal a été purgé en dernier, et qui a fait le dernier changement.

dans Oracle tout ce dont vous avez besoin est généré automatiquement en code SQL, Tout ce que vous avez à faire est de compiler/exécuter; et il est livré avec une application de base CRUD (en fait seul "R") pour l'inspecter.

vous pouvez effectuer l'audit sur une table SQL via des déclencheurs SQL. À partir d'un déclencheur, vous pouvez accéder à 2 tables spéciales ( insérée et supprimée ). Ces tableaux contiennent les lignes exactes qui ont été insérées ou supprimées chaque fois que le tableau est mis à jour. Dans le trigger SQL vous pouvez prendre ces lignes modifiées et les insérer dans la table d'audit. Cette approche signifie que votre audit est transparent pour le programmeur; ne nécessitant aucun effort de leur part ou de toute connaissance de mise en œuvre.

le bonus supplémentaire de cette approche est que l'audit aura lieu indépendamment du fait que l'opération sql ait eu lieu via vos DLLs d'accès aux données, ou via une requête SQL manuelle; (comme l'audit est effectué sur le serveur lui-même).

je fais aussi la même chose. Je crée une base de données pour les plans de leçon. Ces plans ont besoin d'une flexibilité de conversion atomique. En d'autres termes, chaque changement, peu importe comment petit, les plans de leçon doit être autorisée, mais l'ancienne version doit être conservé intact. De cette façon, les concepteurs de leçons peuvent modifier les plans de leçon pendant que les élèves les utilisent.

La façon dont il devrait fonctionner qu'une fois qu'un élève a fait une leçon, leurs résultats sont attachés à la version ils ont terminé. Si un changement est fait, leurs résultats indiqueront toujours leur version.

de cette façon, si un critère de leçon est supprimé ou déplacé, leurs résultats ne changeront pas.

la façon dont je fais actuellement ceci est en traitant toutes les données dans un tableau. Normalement, j'aurais juste un champ id, mais avec ce système, j'utilise un id et un sub_id. Le sub_id reste toujours dans la rangée, à travers les mises à jour et les suppressions. L'id est incrémenté automatiquement. Le le logiciel du plan de leçon sera relié au plus récent sous-ID. Les résultats de l'élève seront liés à l'id. J'ai aussi inclus un horodatage pour suivre les changements, mais il n'est pas nécessaire de gérer le versioning.

une chose que je pourrais changer, une fois que je l'ai testé, est que je pourrais utiliser l'idée d'endDate nulle mentionnée précédemment. Dans mon système, pour trouver la version la plus récente, je dois trouver le max(id). L'autre système recherche simplement endDate = null. Pas sûr si les avantages outway ayant un autre champ date.

mes deux cents.

While @WW. réponse est une bonne réponse une autre façon est de faire une colonne de version et de garder toutes vos versions dans la même table.

pour une approche de table vous soit:

• utilisez un drapeau pour indiquer le dernier ala Word Press
"
• OU de faire un méchant plus que la version outer join .

An L'exemple SQL de la méthode outer join utilisant les numéros de révision est:

SELECT tc.*
FROM text_content tc
LEFT OUTER JOIN text_content mc ON tc.path = mc.path
AND mc.revision > tc.revision
WHERE mc.revision is NULL 
AND tc.path = '/stuff' -- path in this case is our natural id.

la mauvaise nouvelle est que ce qui précède nécessite un outer join et les jointures externes peuvent être lentes. La bonne nouvelle est que la création de nouvelles entrées est théoriquement moins cher parce que vous pouvez le faire dans une opération d'écriture avec les transactions (en supposant que votre base de données est atomique).

un exemple faisant une nouvelle révision pour '/stuff' pourrait être:

INSERT INTO text_content (id, path, data, revision, revision_comment, enabled, create_time, update_time)
(
SELECT
(md5(random()::text)) -- {id}
, tc.path
, 'NEW' -- {data}
, (tc.revision + 1)
, 'UPDATE' -- {comment}
, 't' -- {enabled}
, tc.create_time
, now() 
FROM text_content tc
LEFT OUTER JOIN text_content mc ON tc.path = mc.path
AND mc.revision > tc.revision
WHERE mc.revision is NULL 
AND tc.path = '/stuff' -- {path}
)

nous insérons en utilisant les anciennes données. Ceci est particulièrement utile si vous dites que vous vouliez seulement mettre à jour une colonne et éviter des fermetures et / ou des transactions optimistes.

la table approche par drapeau et approche historique exige que deux" lignes 1519110920 " soient insérées/mises à jour.