-
Notifications
You must be signed in to change notification settings - Fork 103
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
Comments
Très intéressant comme réflexion, sur laquelle je n'ai pas d'avis tranché. 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 ? |
Oui grande question qui n'a pas de réponse unique. Le travail sur le MCD de la synthèse a été suivi ici pour la refonte en V2 : #207 Les différentes solutions ont des avantages et des inconvénients. 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. 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. |
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. 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. |
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 ?
The text was updated successfully, but these errors were encountered: