V2 - Table d'archivage (stockage vertical / transversal)

[jbrieuclp]

Hello,

J'ouvre à mon tour une issue pour proposer un système permettant d'avoir un historiques/archivages des infos de contacts.

Contexte
Chez les entomos (mais pas certainement pas que), selon les groupes plus ou moins connus, il est quasiment primordial d'avoir un suivi des modifications ou des évolutions de la nomenclature. Ça peut être le cas si un groupe est peu connu, ou si la détermination d'un taxon est difficile…

Pour répondre à cette demande j'avais dans un premier temps réfléchi à une structuration de BDD ajoutant une notion d'identification d'une observation. (Une observation pouvant être identifiée une ou plusieurs fois par des déterminateurs différents). En plus du suivi des identifications, l'intérêt que je voyais à cette structuration était celui d'avoir une traçabilité de la nomenclature dans l'évolution du référentiel taxonomique (le fait d'avoir un suivi des identifications d'une observation aurait permis de savoir qu'à une version précédente du référentiel l'identification était différente de la nouvelle...).
Finalement après réflexion, cette notion d'une ou plusieurs identifications pour une observation correspond juste à de l'archivage. Sauf qu'en plus, ce système apporte de la galère tant dans la BD qu'à l'interface... Seulement c'est une notion nécessaire !

Proposition
Je me suis dit qu'un petit triggers déclenché lors d'un UPDATE ferait impeccablement bien le taf d'archivage ! Il suffit de créer une nouvelle table "h_occurences_contact" (h pour historique). Cette table est basée sur la structure de la table t_occurences_contact, on lui ajoute sa propre PK et deux champs pour stocker l'info de la date et de l'utilisateur qui a fait la modification.

Je pense que dans cette table les valeurs et non les clés des tables jointes doivent être stockées (quid du counting ?).
Je pense également qu'il faut permettre le listing des champs qui, s'ils sont modifiés, permettent l'archivage de la ligne. (Ca peut peut-être passer par une table de paramétrage.)
Idem, la table relevé serait-elle a archiver de cette manière ?

[gildeluermoz]

Nous sommes en train de travailler avec le PNCévennes sur une notion générique d'archivage des actions sur les tables (insert, update, delete). La piste serait qq chose de totalement générique reposant sur une sérialisation en json des enregistrements concernés et un stockage dans 2 tables (gn_meta ou un nouveau gn_history ou gn_tracking)
Par contre dans ce cas, l'usage serait, au moins dans un premier temps, uniquement un usage administrateur de données.

Si l'historique doit être accessible en interface, c'est une autre histoire.

On va mettre ici ou ailleurs avec un renvoi, les premiers éléments et échanges à ce propos.

[camillemonchicourt]

Oui l'idée de tracé, log, historique abordée de manière générique dans une table centralisée permettrait de partir sur un mécanisme plus générique et global, pas lié à un module.
Il permettrait d'historiser des actions sur n'importe quel objet en y associant des actions (modification, suppression, validation, identification....).

Le fait de sérialiser les modifications dans un champs JSON unique permet de stocker les modifications de n'importe quel objet sans avoir à recréer les champs de sa structure de BDD.
De plus PostgreSQL gère de mieux en mieux les infos JSON.

L'approche par trigger semble la plus intéressante car elle permet de ne pas alourdir l'interface.
En ayant un mécanisme et une table unique, il serait plus facile d'afficher ces infos au niveau de l'interface.
Pour chaque log d'une action sur un objet, il serait nécessaire de stocker le type d'objet, son ID, le type d'action, l'utilisateur et les valeurs.

Voici la première modélisation faire par le PnCevennes sur laquelle nous discutons actuellement :

• Ça veut dire que l'on ne gère plus les dates de modif/creation dans chaque table mais dans cette table centralisée
• Idem pour le booleen DELETED. Ça aussi c'est une bonne chose. Ainsi quand on supprime un objet dans une table, on le supprime vraiment de la table mais on garde sa trace dans ces tables d'historique, en sérialisant dans un champs JSON ses attributs. Ainsi on n'aura plus à faire WHERE DELETED=False à chaque fois qu'on veut lister les objets d'une table

C'est à discuter/affiner car on n'est pas encore au clair sur la modélisation et le fonctionnement.

[jbrieuclp]

Le stockage en json declenché par triggers me semble être une bonne idée, à voir les capacité de postgres à exécuter des recherche sur un champ json... (trouve moi dans l'historique concernant la table XX les données dont l'ID_YYY = ZZZ ?) Par contre sauvegarder l'état d'une ligne brute avec ses FK ne me semble pas intéressant, si la valeur d'une FK change, si l'on a que la clé, on perd l'historique. Si on stocke la valeur associée à la FK, là c'est bonheur !
Après ces différentes choses dépendent du besoin qui justifie cet archivage.

[camillemonchicourt]

Dans ce qui est prévu, seul les attributs sont prévus d'être stockés dans un champs en JSON.
Les ID des objets, leurs tables, types etc... seraient dans des champs dédiés.

[camillemonchicourt]

Le PNC a pensé a un mécanisme plus global, plus propre et plus générique pour les tables de stockage transversal. Cela permet notamment de ne pas répéter les noms de schéma et de table dans chaque enregistrement. Ca pourra être utilisé pour le suivi des actions sur un objet mais aussi pour les médias, la validation :

Une table centralise la liste de tous les objets existants dans GeoNature et leur attribut un id_object unique. Une BIB liste les types d'objets et leur localisation dans la BDD.

[camillemonchicourt]

• Problème de performances car pas de clé étrangère ? On fait un index mais on a pas de clé étrangère. A tester.
• uuid_source plutôt que id_source qui est le même dans la table source et la synthèse. Il peut même remplacer id_object. C'est la clé primaire donc indexé.