Versioning des objets persistants de la base de données, Comment le feriez-vous ?

Question

(Non lié au versionnement du schéma de la base de données)

Les applications qui s'interfacent avec des bases de données ont souvent des objets de domaine qui sont composés de données provenant de plusieurs tables. Supposons que l'application prenne en charge le versioning, au sens du CVS, pour ces objets de domaine.

Pour un objet de domaine d'arbitrage, comment concevriez-vous un schéma de base de données pour répondre à cette exigence ? Avez-vous une expérience à partager ?

Answer 1

Réfléchissez bien aux exigences en matière de révisions. Une fois que votre base de code aura intégré le suivi de l'historique dans le système opérationnel, la situation deviendra très complexe. Assurance souscription systèmes sont particulièrement mauvais à cet égard, avec des schémas dépassant souvent les 1000 tables. Les requêtes ont également tendance à être assez complexes, ce qui peut entraîner des problèmes de performances.

Si l'historique n'est vraiment nécessaire que pour l'établissement de rapports, envisagez de mettre en œuvre un système transactionnel "d'état actuel" avec une structure d'entrepôt de données à l'arrière pour le suivi de l'historique. Des dimensions qui changent lentement constituent une structure beaucoup plus simple pour le suivi de l'état historique que d'essayer d'intégrer un mécanisme ad hoc de suivi de l'historique directement dans votre système opérationnel.

Aussi, Capture des données modifiées est plus simple pour un système "à l'état actuel" dans lequel des modifications sont apportées aux enregistrements en place - les clés primaires des enregistrements ne changent pas et il n'est donc pas nécessaire de faire correspondre des enregistrements contenant différentes versions de la même entité. Un mécanisme CDC efficace rendra le processus de chargement incrémentiel d'un entrepôt assez léger et pourra être exécuté assez fréquemment. Si vous n'avez pas besoin d'un suivi à la minute près de l'état historique (presque, mais pas tout à fait, un oxymore), ce mécanisme peut être une solution efficace avec une base de code beaucoup plus simple qu'un mécanisme complet de suivi de l'historique intégré directement dans l'application.

Answer 2

Une technique que j'ai utilisée pour cela dans le passé a été d'avoir un concept de "générations" dans la base de données, chaque changement incrémente le numéro de génération actuel pour la base de données - si vous utilisez subversion, pensez aux révisions. Chaque enregistrement est associé à deux numéros de génération (deux colonnes supplémentaires dans les tables) - la génération pour laquelle l'enregistrement commence à être valide et la génération pour laquelle il cesse d'être valide. Si les données sont actuellement valides, le deuxième numéro sera NULL ou un autre marqueur générique.

Donc pour insérer dans la base de données :

1. incrémenter le numéro de génération
2. insérer les données
3. étiqueter la durée de vie de ces données avec un début de validité et une fin de validité de NULL.

Si vous mettez à jour certaines données :

1. marquer toutes les données qui sont sur le point d'être modifiées comme valides au numéro de génération actuel
2. incrémenter le numéro de génération
3. insérer les nouvelles données avec le numéro de génération actuel

La suppression consiste simplement à marquer les données comme se terminant à la génération actuelle.

Pour obtenir une version particulière des données, trouvez la génération que vous recherchez et recherchez les données valables entre ces versions de génération.

Ejemplo:

Créez une personne.

|Name|D.O.B  |Telephone|From|To  |
|Fred|1 april|555-29384|1   |NULL|

Mise à jour du numéro de téléphone.

|Name|D.O.B  |Telephone|From|To  |
|Fred|1 april|555-29384|1   |1   |
|Fred|1 april|555-43534|2   |NULL|

Supprimez Fred :

|Name|D.O.B  |Telephone|From|To  |
|Fred|1 april|555-29384|1   |1   |
|Fred|1 april|555-43534|2   |2   |

Answer 3

Une alternative à la gestion stricte des versions est de diviser les données en 2 tableaux : courant et historique.

Le tableau actuel contient toutes les données en temps réel et bénéficie de toutes les performances que vous avez intégrées. Tout changement écrit d'abord les données actuelles dans la table "historique" associée avec un marqueur de date qui indique la date du changement.

Answer 4

Si vous utilisez Hibernate JBoss Envers pourrait être une option. Il suffit d'annoter les classes avec @Audited pour conserver leur histoire.

Answer 5

Vous aurez besoin d'une fiche dans une table de base qui contient les informations communes à toutes les versions.

Ensuite, chaque table enfant utilise l'identifiant de la fiche + le numéro de version comme partie de la clé primaire.

Il est possible de le faire sans la table principale, mais d'après mon expérience, cela rendra les instructions SQL beaucoup plus désordonnées.