Versionning des données d'une base [Résolu]

[PierreY]

Salut,

Est-ce qu'il existe un "design pattern" répondant au problème du versionning des données dans une base de données ? Je veux pouvoir tracer toutes les versions de toutes les données d'une base de données. Et pouvoir, avec les requêtes judicieuses retrouver les données de la base à n'importe quelle version (comme avec SVN ou CVS).

Merci d'avance,

--
Pierre Y.

[xss.xas]

Cette histoire de versionning m'intéresse

Je me permet d'exposer mon problème ici, qui semble s'en rapprocher.

Mes utilisateurs doivent saisir des formulaires, qui constituent un document.
Ce document peut être mis à jour, et il faut conserver un historique de toutes les modifs faites sur ce document (ce document, concrètement, c'est un enregistrement dans une table).

La première idée qui m'est venu est d'ajouter un champ "codeMAJ" au document, et de dupliquer l'intégralité des champs qui n'ont pas été modifiés. C'est très facile à mettre en place mais peu économe (49 champs dupliqués pour 1 champ mis à jour, le mot "LOURD" n'est pas à prendre à la légère ... arhem :p). Cependant, on retrouve bien les différentes révisions du document, telles qu'elles étaient au moment de leur saisie.

L'autre idée qui m'est venu (mais qui me semble dangereuse), est d'ajouter une table de ce style là:

SCH.MAJDOC(#*idDoc, #idMAJ, nomChamp, typeChamp, valeurChamp).
- valeurChamp étant un type "large" (String me suffirait, mais Object marche à 100%)
- typeChamp étant une chaîne définissant le type ("VARCHAR", "INTEGER", "DATE", etc.) de valeurChamp
- nomChamp, le nom du champ mis à jour dans le document.

Que pensez-vous de cette méthode ? Elle devient rentable si le nombre d'enregistrements dans la table d'origine est conséquent, mais je n'arrive pas à cerner ce qu'implique sa mise en oeuvre.

Ici il s'agit plutôt d'un versioning d'enregistrements, mais je suis également ouvert à suggestions

[SQLpro]

en dehors des deux solutions classiques évoqués il en existe une 3e qui consite à rajouter dans toutes les tables une colonne TIMESTAMP avec la date/heure d'obsolèscence de la version de ligne. Pour l'unique ligne valide dans le présent, cette datheure doit être une valeur dans un futur très éloigné, par exemple '9999-01-01'.

Pour la manipulation des tuples, rien de plus simple...
Ajoutez à chaque table une vue avec le filtre suivant :
CREATE VIEW V_ACTUAL_DATA
AS
SELECT <toutes les colonnes sauf celle d'horodatage>
FROM <ma_table>
WHERE maColonneHorodatage > CURRENT_TIMESTAMP

Bien entendu il faudra rajouter des triggers pour gérer les DELETE ET UPDATE.

A +

[lunatix]

a mon avis, ca dépends aussi de la charge de ton application et du nombre d'enregistrement et de versions qu'il y aura dedans.

A partir d'une certaine charge, tu es obligé de ne garder que la version courante, et d'archiver les vieilles versions dans une autre table, qui sera moins utilisée. (Bien sur, ca depends aussi de l'utilisation, si a chaque ouverture de formulaire on consulte aussi l'historique, ca sert a rien )

[GyLes]

Hello,

Les fonctionnalités de versionning d'une SGBDO intègrent nativement la partie timestamp.

Lors de la création d'un objet, il suffit de spécifier que cet objet sera versionné.
Le langage OQL permet via des crochets de spécifier sur quel version de l'objet travailler. La version ou le timestamp permettent ainsi d'interroger la base historiquement.