Lors de la mise à jour, il faudrait simplement mettre à jour les valeurs dans les champs correspondant et non pas changer les intitulés de colonnes. Résultat beaucoup plus de flexibilité, toutes les informations utiles sont présentes dans la vue : l'unité, l'année, l'échelle, etc.
On se retrouverait dans le backoffice avec une source postgis pour un indicateur statistique, et toutes les couches relatives à cet indicateur pointant sur cette source.
On aurait autant de source que d'échelle pour un même indicateur (par ex : évolution de la population / commune, epci, département).
Développements à réaliser dans le backoffice
Au niveau de l'intégration des couches comme groupe par variable dans le backoffice, on pourrait utiliser les champs année et échelle comme variable (pointe sur une colonne) ou rentrer le nom des couches à la main.
Une vue SQL = un indicateur
Lors de la mise à jour, il faudrait simplement mettre à jour les valeurs dans les champs correspondant et non pas changer les intitulés de colonnes. Résultat beaucoup plus de flexibilité, toutes les informations utiles sont présentes dans la vue : l'unité, l'année, l'échelle, etc.
On se retrouverait dans le backoffice avec une source postgis pour un indicateur statistique, et toutes les couches relatives à cet indicateur pointant sur cette source.
On aurait autant de source que d'échelle pour un même indicateur (par ex : évolution de la population / commune, epci, département).
Développements à réaliser dans le backoffice
Au niveau de l'intégration des couches comme groupe par variable dans le backoffice, on pourrait utiliser les champs année et échelle comme variable (pointe sur une colonne) ou rentrer le nom des couches à la main.
modeles_vues_sql.ods