Permet de définir des requêtes SQL différentes pour certaines mailles

Contexte

Notre modèle utilise une requête SQL de base, à laquelle on ajoute un filtre en fonction de la maille, et éventuellement une jointure automatique du référentiel géographique selon la maille des données.

Ce modèle fonctionne bien pour la plupart de nos jeux de données et indicateurs, mais rencontre parfois des limites.

On a ainsi permis d’avoir plusieurs mailles d’origine, de manière à pouvoir filtrer sur différentes colonnes selon la maille, lorsque les données ont déjà par exemple une colonne insee_dep et une colonne insee_reg, et que les valeurs à la maille régionale ne sont pas une simple aggrégation des valeurs à la maille département.

Une autre limite que l’on a rencontré (par exemple avec deveco), c’est lorsque les données concernant différentes mailles sont dans des tables différentes. On aimerait alors pouvoir écrire une requête SQL différente pour chaque maille. On peut s’en sortir en créant une vue qui fusionne les deux tables, mais c’est alambiqué, et ne marche pas avec la maille nationale.

Contenu

On permet de surcharger la requête SQL de base pour certaines mailles :

- identifiant: mon_indicateur
  sql: SELECT SUM(col) FROM table1
  mailles:
    - commune:
        sql: SELECT SUM(col) FROM table2
    - département
    - région
    - national

Cela nécessite d’expliciter toutes les mailles cibles même si on ne veut surcharger la requête que pour l’une d’entre elles. Mais je me dis que "explicit is better than implicit" donc ça me semble acceptable.

Alternatives

Je me suis demandé si on pouvait exprimer ça différemment, par exemple :

- identifiant: mon_indicateur
  sql: SELECT SUM(col) FROM table1
  overrides:
    - commune:
        sql: SELECT SUM(col) FROM table2

Ou encore :

- identifiant: mon_indicateur
  sql:
   default: SELECT SUM(col) FROM table1
   commune: SELECT SUM(col) FROM table2

Mais ça introduit des mots clés supplémentaires, et j’anticipe qu’on voudra peut-être permettre de surcharger d’autres paramètres dans le futur, comme colonne_geo, et je me dis que je préfère la structure où on les regroupe par maille plutôt que par paramètre.