Gestion des champs spécifiques à un jeu de données

[sig-pnrnm]

Ayant beaucoup pratiqué l'importation de données hétérogènes, on rencontre de manière incontournable des champs spécifiques à chaques jeux de données.

Faire le matching de ces champs (et de leurs nomenclatures) avec les champs d'un modèle est au minimum très chronophage... bien souvent impossible.

Mais plutôt que de perdre ces infos (parcequ'on n'a pas le courage de perdre tout ce temps de "matching"), il y a plusieurs méthodes pour les conserver en base.

Dans ma jeunesse, je basculais ces infos dans le champ "commentaire", accompagnées du nom du champ (ou de sa traduction française). Exemple de commentaire :

2 individus observés à 22h30 [météo : ciel dégagé] [vent : léger] [température : 18°c] [nombre de poils : 27]

J'ai découvert récemment les champs de type hstore de PostGreSQL (https://docs.postgresql.fr/10/hstore.html), qui utilisent la notion de "clé/valeur", sur le même principe que les tags OpenStreetMap.

Il me semble que ce serait une bonne pratique pour conserver ces champs spécifiques (pas de perte d'info). Cela permet ensuite d'écrire des requêtes qui interrogent ces champs spécifiques conservés en base, sans avoir eu a créer autant de champs à usages uniques.

[DonovanMaillard]

Le module d'import tel qu'il est conçu pour l'instant stocke déjà en base l'ensemble des champs fournis dans la source.

Les mapping (champs et contenus) ne sont effectués que vers les champs et les nomenclatures de la synthèse, pour permettre le transfert des données sources vers la synthèse. Les champs spécifiques, qui ne sont donc pas dans la synthèse, ne sont pas visés par les mappings, et la donnée source est stockée dans une table d'import qui lui est propre, avec l'ensemble des champs sources ;)

A noter que pour les cas les plus compliqués, le module est un module d'aide à l'import des données pour l'administrateur. Il ne pourra pas répondre à tous les cas particuliers, qui resteront à traiter en sql par l'admin ;)

Les attributs additionnels (météo, nombre de poils etc) seront donc stockés en base mais pas consultables en synthèse. Si l'admin veut rendre les infos dispo dans son champs commentaire, il pourra concaténer ces champs supplémentaires dans sa table d'import, et le mapper comme étant un champs "commentaire de l'occurrence".

[camillemonchicourt]

C'est que pour les champs en plus non mappes, ça pourrait être une évolution intéressante que de pouvoir les concaténer dans le champs Commentaire.

Évolution pour plus tard.

[sig-pnrnm]

la donnée source est stockée dans une table d'import qui lui est propre, avec l'ensemble des champs sources

OK, c'est parfait alors ! :)

ça pourrait être une évolution intéressante que de pouvoir les concaténer dans le champs Commentaire.

C'est pour ça que je proposais les champs de type "hstore", qui font bien mieux qu'une "concaténation", car ils permettent d'être requétés.

Évolution pour plus tard.

Pas de souci ;)

[DonovanMaillard]

Oui, cette concaténation ou ce type hstore (que je ne connais pas) étaient pas prévus, je suis pas fan de tout mettre dans le commentaire donc je n'y avais pas pensé. Mais pourquoi pas si c'est au choix de l'utilisateur en effet, faut pas que ca se fasse par défaut

On peut même, dans ce cas, imaginer un objet multiselect pour choisir les champs additionnels à rentrer dans le commentaire... en restant sur la conclusion "évolution pour plus tard" :)

[amandine-sahl]

Sinon, les champs supplémentaires peuvent être stockés dans une table particulière (gn_synthese.synthese_extra_fields) avec 3 colonnes (id_synthese, nom_champ, valeur_champ) ce qui permettrait de pouvoir unifier les données additionnels des différentes sources et de pouvoir les interroger de façon croisée (sans avoir à revenir sur chacune des tables).

[camillemonchicourt]

Autre piste assez similaire à celle proposée par @amandine-sahl : Le standard Occurrence de taxons prévoit la gestion de "Champs additionnels". Le jour où les implémentera, ils pourraient servir à garder ces infos qui ne collent avec aucune des nomenclatures.

[DonovanMaillard]

Merci pour l'idée! En effet, à voir si c'est utile à certains.

Pour le moment ce n'est pas planifié (c'est mon usage "SINP" qui fait que j'ai voulu conserver les tables sources et leurs infos plus facilement identifiables). Mais selon les besoins ca peut devenir une évolution également oui, même si ca me semble compliquer beaucoup les choses en termes de visualisation / export des données sources.

Pour @camillemonchicourt en effet, c'est pour cette notion qu'il nous a semblé important de conserver la source...