[suivi-eolien] Supprimer id_nomenclature_type_site de t_base_sites

[amandine-sahl]

A réaliser au niveau de GeoNature, même si cela peut poser des soucis car la table cor_type_site est créée au niveau du module monitoring.

[amandine-sahl]

La gestion du modèle de monitoring est assurée par deux entités GeoNature et Monitoring. Cette séparation un peu arbitraire pose problème dans le contexte de la refonte actuelle de monitoring notamment le passage de id_nomenclature_type_site en valeur multiple (création de la table cor_type_site +… dans le module monitoring).

La version multiprotocole ajoute les tables suivantes qui devrait être dans le coeur de GeoNature :

• cor_module_type
• bib_type_site
• cor_type_site
  ce qui entraine par conséquence la suppression de id_nomenclature_type_site de la table t_base_site hors le modèle t_base_site est dans le coeur de geonature.

Pour être plus cohérent il faudrait peu être repenser les migrations et la gestion des modèles pour les déporter au maximum dans le coeur de GeoNature (S1) voir aller vers la suppression des tables de complément et leur transfert dans un champ additional_data (S2).

tables	GeoNature	monitoring	S1 GN	S1 monitoring	S2 GN	S2 monitoring
t_base_sites	x		x		x
cor_site_module	x		x		x
cor_site_area	x		x		x
t_base_visits	x		x		x
cor_visit_observer	x		x		x
t_module_complement		x		x		x
t_sites_groups		x		x	x
t_site_complement		x		x	NA	NA
t_visit_complement		x		x	NA	NA
t_observations		x	x		x
t_observation_complement		x		x	NA	NA
t_observation_detail		x		x	x
cor_module_type		x	x		x
bib_type_site		x	x		x
cor_type_site		x	x		x

[camillemonchicourt]

Oui comme évoqué dans d'autres issues, je suis favorable à basculer le maximum (tout ?) de la BDD et de l'API dans GeoNature et de supprimer les tables de compléments.

[camillemonchicourt]

S1 fait dans la PR PnX-SI/GeoNature#2824, intégrée à GN 2.15.
A voir si il faut aller vers S2 dans un second temps ?