Discussion :

[eXiaNazaire]

Bonjour à tous,

J'ai étudié les quelques sujets qui traitent d'historisation sur ce forum et je n'arrive pas à trouver une réponse à ma problématique c'est pourquoi je me permets de vous l'exposer.

Je travaille sur un projet plus moins conséquent qui exploitent de nombreuses entités. Les cas d'utilisations du systèmes sont nombreux, mais se rapproches à chaque fois de cas d'utilisation simples CRUD (Create, Research, Update, Delete).

Par exemple un utilisateur va pouvoir ajouter/modifier/supprimer une "Mission" ou ajouter/modifier/supprimer un "Rapport de mission" ou il pourra ajouter/modifier/supprimer un "Matériel", etc.

Bien sûr il y'a d'autres cas d'utilisation moins simples, mais ce n'est pas le problème.

Ma problématique générale serait d'historiser les opérations sur ces entités.

Mes contraintes seraient :
1/ Concevoir une solution qui ne prend pas trop d'espace disque sur la base de données
2/ Un besoin "fonctionnel" de conserver les données de l'instant T de l'historisation.
3/ (Si possible) De trouver une solution générique pour toutes les entités concernées.
4/ Toutes celles que je n'ai pas encore identifiées et qui pourtant existent.

Les solutions envisagées :
A ce jour, avec mon faible niveau en conception de modèle de données. Je pense aux solutions suivantes :

Solution Générique 1 - Historisation par Id

Gérer une table "historique" dans laquelle on pourrait inscrire l'id de l'entité historisé, un login et une date.

Cette solution très simple, présente déjà des inconvénients non négligeables. En effet cette solution ne permet pas de conserver les données de l'instant T de l'historisation, par contre elle permet de garantir une historisation "Light" en espace disque.


Solution Générique 2 - Historisation par copie de données
Dans ce cas on gère une table "historique", dans laquelle on va copier les données au moment de l'historisation.
Par exemple lors de l'ajout d'une mission, on va copier dans la table historique, le titre de la mission, la description de la mission, la durée de la mission, le login, nom, prénom, information sur l'utilisateur qui effectue l'ajout et la date.
En cas de modification de la mission, on fait pareil, on copie toutes les données.

L'avantage d'un tel système est on assure la conservation de l'information à l'instant T de l'historisation: Le désavantage est que ça peut prendre vite énormément de place en base.
Inconvéniant, comment faire une seule table historique pour gérer toutes les entités (Sachant que les attributs ne sont pas les mêmes)

Voilà pour les grandes idées ultra simples de mon esprit simpliste ! Pour résumer mes 2 cas, dans un cas j'historise un état "Mission - Modifiée - Le xx/xx/xxxx - Par Y" et dans l'autre cas j'historise carrément les données pour des raisons purement fonctionnelles.

Voilà ma question est donc de savoir s'il existe un modèle (pattern) plus intelligent que mes idées (J'en doute pas) concernant cette problématique qui a du être rencontrée des milliers de fois ?! (Que fait le Gang of four ?)

Quelles sont les bonnes questions à se poser dans ces cas là, pour construire le modèle de données le plus solide possible.

A vous les studios ...

[Tommy31]

Complexe ton affaire. Et dépend finalement de ton besoin réel.

Si ton besoin est de consigner dans un journal (un historique), les différentes modifications apportées (un change log en gros) alors ta solution 1 est bonne, à condition qu'elle recèle suffisamment de détail pour être exploitable.

Si ton besoin est de pouvoir revenir à une ancienne version, ou d'avoir une vue de consultation d'un ancien état alors il faut une autre stratégie. Là c'est la solution 2, éventuellement gérée au travers du pattern Memento. Il est possible de tout stocker au sein d'une unique table en sérialisant les attributs des objets dans un unique attribut. Il est également possible, en rusant un peu, de gagner en place en générant une sérialisation textuelle, d'en faire un diff, et de stocker ce diff (éventuellement compressé) dans l'attribut. Mais alors pour revenir à une version n-2, il faut 2 étapes de reconstruction d'objet.