Avec l'arrivée des Fichiers fonciers 2025, le format de livraison en SQL évolue afin de s’adapter aux bonnes pratiques actuelles de PostgreSQL et de mieux distinguer les périmètres de données.

1. Abandon du principe d’héritage de tables sous PostgreSQL

Jusqu’à présent :

• Les tables départementales (dites « filles ») étaient présentes dans un schéma suffixé par __dep.
• Un schéma mère permettait d’accéder à l’ensemble via le mécanisme d’héritage de tables.

➡️ Ce mécanisme n’étant plus recommandé dans les versions récentes de PostgreSQL, il est désormais abandonné.

Désormais :

• Le script ff_init.sql crée directement la structure de données.
• Les scripts départementaux ff_dXX.sql (où XX = numéro de département) peuplent des tables uniques avec les données correspondantes.

2. Dissociation entre tables nationales agrégées et tables locales

Avant :

• Les tables agrégées nationales (régions, départements, carreaux 10 km, etc.) étaient livrées systématiquement et intégrées au schéma mère, sans distinction avec les tables locales.

Désormais :

• Elles sont restaurées indépendamment.
• Elles se trouvent dans un schéma spécifique ff_national
• Les données locales restent dans le schéma ff.

3. Nouvelles conventions de nommage des schémas et tables

Avant :

• ffAAAA : schéma mère (tables agrégées nationales + tables mères vides).
• ffAAAA_dep : schéma fille (tables départementales).
• Les noms de tables étaient préfixés par fftp_AAAA_table ou ffta_AAAA_table.

Désormais :

• ff : tables principales et agrégées correspondant au périmètre de la structure demandeuse.
• ff_national : tables agrégées nationales, communes à toutes les livraisons.
• Les préfixes de table deviennent simplement fftp_ ou ffta_. L'année de millésime est définie en fin de table de manière à regrouper les mêmes tables millésimées lors de la visualisation du schéma.

👉 Exemple : fftp_2024_pnb10_parcelle devient fftp_pnb10_parcelle_2024.

4. Principe de restauration du nouveau format SQL

1. Exécuter ff_init.sql → création de la structure.
2. Charger les scripts ff_dXX.sql selon les départements concernés → alimentation des données locales.
3. Si besoin, charger les tables nationales en restaurant ff_agg_national.sql.

👉 Pour plus de détails techniques : [voir la fiche SQL].

5. Compatibilité avec l'ancien format

Pour des raisons de compatibilité, il est possible de recréer l’ancienne nomenclature (avec l’année dans les noms de tables) via des vues.

Exemple : création d’un schéma ff2025 avec des alias vers les nouvelles tables du schéma ff.

-- Génération automatique : script dynamique pour toutes les tables locales
DO $$
DECLARE 
    rec RECORD;
BEGIN
    EXECUTE 'CREATE SCHEMA IF NOT EXISTS ff2025';
    FOR rec IN 
        SELECT tablename 
        FROM pg_tables 
        WHERE schemaname = 'ff'
          AND (tablename LIKE 'fftp%2025' OR tablename LIKE 'ffta%2025')
    LOOP
        EXECUTE format(
            'CREATE OR REPLACE VIEW ff2025.%s_%s AS SELECT * FROM ff.%s;',
            substring(rec.tablename FROM 1 FOR 4),  -- fftp ou ffta
            '2025' || substring(rec.tablename FROM 5 FOR (char_length(rec.tablename) - 9)),
            rec.tablename
        );
    END LOOP;
END$$;

👉 Ce script permet :

• de reconstituer automatiquement des vues (fftp_2025_*, ffta_2025_*) à partir des nouvelles tables (fftp_*, ffta_*),
• de conserver la compatibilité ascendante pour les outils et requêtes déjà en production.