Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Pourquoi la synthèse à plat ? #924

Open
jbrieuclp opened this issue May 14, 2020 · 3 comments
Open

Pourquoi la synthèse à plat ? #924

jbrieuclp opened this issue May 14, 2020 · 3 comments

Comments

@jbrieuclp
Copy link
Contributor

La grosse question douloureuse qui met en cause le nerf central de geonature !
Ce n'est pas une issue, mais une réflexion que je veux partager.

Niveau performance et stockage disque cette table gn_synthese.synthese est une aberration qui respecte le principe du SINP mais pas vraiment celui d'une base de données.

Il serait intéressant qu'à l'instar d'occtax qui factorise les données en relevés, occurrences, dénombrements, la synthèse soit basée sur une structuration équivalente et qu'une vue permette une restitution des données à plat.

Toutes les requêtes et surtout les requêtes spatiales seront optimisées (croisement, asGeosjon) et de nombreux triggers pourraient probablement disparaître (cor_area_synthese, cor_area_taxon..)

La table plate de la synthèse est très facile pour pouvoir importer des données externe dans geonature, c'est bien plus simple que d'éclater les données dans 3 tables différentes (4 avec les observateurs). Mais est-ce qu'avec le module d'import finalisé ou en voie de l'être, ce format plat à un réel intérêt ?

@camillemonchicourt camillemonchicourt changed the title Pourquoi la synthèse ? Pourquoi la synthèse à plat ? May 14, 2020
@jbdesbas
Copy link
Contributor

Très intéressant comme réflexion, sur laquelle je n'ai pas d'avis tranché.
A noter que la synthèse n'est pas totalement à plat, mais qu'un certain nombres d'informations cohérentes sont déjà factorisées via la gestion des métadonnées.

Ce qui est à réfléchir c'est si le système à 3 tables (relevés, occurrences, dénombrement) s'appliquerait à n'importe quel protocole ? J'y vois par exemple une difficulté pour les suivis individus-centrés, pour lesquelles le regroupement par "relevés géographique" aura moins de sens. (car supposerait de créer une multitudes de relevés, pour des observations rapprochées dans le temps et sur le même sujet).

Concernant les géométries, il y a effectivement une forte redondance dans la table synthèse. Je ne sais pas si PostGIS optimise les requêtes sur les tables ayant beaucoup de géométries identiques ?
Peut-être déjà regrouper et stocker les géométries à part, avec simplement un id_geom dans la synthèse ?

@camillemonchicourt
Copy link
Member

camillemonchicourt commented May 15, 2020

Oui grande question qui n'a pas de réponse unique.
C'est un choix historique de GeoNature V1 où la synthèse est à plat et la donnée plus complexe est au niveau des sources et protocoles.
En 2017, quand on a initié les réflexions sur la V2 (https://geonature.fr/documents/2017-09-GN2-Fonctionnalites-0.2.pdf), on a reposé tous ces sujets sur le tapis.

Le travail sur le MCD de la synthèse a été suivi ici pour la refonte en V2 : #207
A ce moment, on a aussi investigué le fait qu'Occtax et la Synthèse aient un cœur commun, qui puisse aussi être partagé avec d'autres protocoles : #171 / #183

Les différentes solutions ont des avantages et des inconvénients.
Là on a un partie pris clair et qui permet de gérer les différents cas : Modèle relationnel dans les sources et protocoles, table à plat pour la mise en commun dans la Synthèse.
A l'usage je trouve toujours ce choix bon. C'est vrai que la majorité de nos données Occtax ont 1 relevé = 1 taxon. Et que la quasi-totalité des données fournies par les partenaires sont du même type, donc ré-éclater ça en modèle relationnel à plusieurs niveaux amènerait pas mal de complexité pour un gain limité.

On avait aussi discuté du cas des géométries ici qui est le cas qui pose le plus de questions de stockage et de duplication : #45.
Là c'est encore plus limite avec les observations rattachés à des communes par exemple, mais on a gardé le choix de stocker la géométrie du rattachement dans la synthèse, en plus de l'id_area : #867

Pour la sensibilité etc... par contre on rattache uniquement à des id_area.

On peut réfléchir ce sujet cependant, au sein du COTECH ou pour une V3.

En tout cas, de notre côté, ce choix est discutable mais on en est content.

@gildeluermoz
Copy link
Contributor

Effectivement ce serait pour une V3. La synthèse est tellement centrale que revoir sa structure en base aurait d'importantes conséquences partout dans la base et dans le code.
Sans parler du script de migration de la base...

A noter tout de même qu'on avait tenté de rompre avec ce modèle à plat pour les nomenclatures et qu'on est revenu en arrière pour des questions de performances.

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

4 participants