Migrer une base HFSQL vers PostgreSQL

PostgreSQL est notre cible par défaut pour les sorties de HFSQL : libre, sans coût de licence, éprouvé sur des volumétries qui dépassent largement celles d'une application de gestion, et doté du typage le plus rigoureux du marché. Cette page décrit la méthode d'extraction et les pièges spécifiques au couple HFSQL / PostgreSQL.

Pourquoi PostgreSQL est la cible par défaut

• Aucun coût de licence, quel que soit le nombre de postes ou de serveurs : la question de la redevance disparaît définitivement.
• Rigueur du typage et des contraintes : la base devient le gardien de la cohérence des données, rôle que HFSQL laissait au code applicatif.
• Écosystème complet : sauvegarde, réplication, supervision, hébergement managé chez tous les fournisseurs cloud.
• Compatibilité universelle : toutes les stacks cibles (.NET, PHP, Java, Node) disposent de pilotes de premier rang.

Extraction : les 3 méthodes possibles

Notre pratique : la troisième voie dès que la base dépasse quelques dizaines de tables ou que la bascule se fera par vagues. Un extracteur rejouable transforme la migration de données en opération répétable et vérifiable, au lieu d'un moment de vérité unique un dimanche soir.

Mapping des types et des index

L'essentiel du schéma se transpose sans drame : textes, entiers, dates, décimaux trouvent leurs équivalents PostgreSQL plus stricts. Les points d'attention réels : les mémos et binaires (vers text et bytea), les dates vides ou sentinelles de HFSQL à convertir en NULL explicites, les chaînes à normaliser en UTF-8, et les identifiants automatiques à recréer en séquences. Chaque règle de conversion s'écrit dans un dictionnaire de mapping qui fait partie des livrables : c'est lui qui rend la recette possible.

Les index se reconstruisent plutôt qu'ils ne se copient : PostgreSQL offre des types d'index plus riches, et les habitudes de requêtage de la nouvelle application ne seront pas celles de l'ancienne. On repart des requêtes réelles, pas de l'historique.

Ce que HFSQL fait et que PostgreSQL fait autrement

Le piège principal n'est pas dans les types, il est dans les habitudes. L'intégrité référentielle, souvent déclarative ou partielle côté HFSQL, devient contraignante côté PostgreSQL : les orphelins tolérés pendant des années bloquent le chargement, et c'est une bonne nouvelle, à condition d'avoir prévu la phase de nettoyage. Les parcours ligne à ligne du WLangage doivent devenir des requêtes ensemblistes. Et les recherches insensibles à la casse ou aux accents, implicites dans HFSQL, se déclarent explicitement (collations, index dédiés) sous peine de surprises fonctionnelles.

Recette et contrôle d'intégrité

• Comptages par table, totaux financiers et agrégats métier comparés entre source et cible.
• Échantillonnage ciblé sur les cas limites : caractères spéciaux, dates extrêmes, enregistrements les plus anciens.
• Rejeu complet de la migration à blanc, chronométré, avant toute bascule réelle.
• Période de double-run quand le métier l'exige : l'ancienne base reste alimentée en parallèle le temps de valider.

Erreurs fréquentes sur une migration vers PostgreSQL

• Charger les données avant d'avoir figé le dictionnaire de mapping des types : chaque correction ultérieure impose de tout recharger, ce qui allonge le chantier au lieu de le raccourcir.
• Copier les index existants sans les repenser : les habitudes de requêtage de HFSQL ne sont pas celles de la nouvelle application, et un index copié tel quel peut ne servir à rien côté PostgreSQL.
• Reporter le nettoyage des orphelins détectés par les nouvelles contraintes d'intégrité : les traiter au fil de l'eau, table par table, évite un chantier de correction massif juste avant la bascule.
• Négliger le rejeu à blanc chronométré : c'est lui qui révèle si la fenêtre de bascule prévue est réaliste, avant que la date ne soit fixée et communiquée.

La plupart de ces erreurs partagent une cause commune : traiter la migration de base comme une opération purement technique, alors qu'elle engage des décisions métier à chaque étape (que faire d'un orphelin, comment nommer une colonne ambiguë, quelle valeur donner à une date manquante). C'est pourquoi le dictionnaire de mapping se construit avec les personnes qui connaissent le métier, pas seulement avec celles qui connaissent le schéma.

Points de vigilance à l'audit avant la migration

L'audit qui précède une migration HFSQL vers PostgreSQL vérifie systématiquement l'état réel des contraintes d'intégrité (déclarées ou seulement gérées par le code), le volume d'enregistrements orphelins déjà présents, la cohérence des jeux de caractères utilisés au fil des années, et l'existence ou non de traitements par lots qui devront être repensés en requêtes ensemblistes. Ces quatre points, mesurés avant tout chiffrage, évitent les mauvaises surprises en cours de chantier.

Durée type

Un chantier HFSQL vers PostgreSQL se compte en semaines : l'écriture de l'extracteur et du mapping en constitue le cœur, les rejeux et la recette le reste. La volumétrie brute pèse moins que la complexité du schéma et la qualité des données existantes. L'audit initial en donne une estimation fiable, car c'est l'un des six axes qu'il mesure précisément.