Migrer une base HFSQL vers MySQL ou MariaDB

MySQL et son fork communautaire MariaDB restent les bases les plus déployées du web. Pour une sortie de HFSQL, elles constituent une cible légitime dans des cas précis, notamment quand la trajectoire applicative passe par PHP ou WordPress. Cette page situe honnêtement leurs forces face à PostgreSQL et déroule la méthode d'extraction.

MySQL, MariaDB ou PostgreSQL ?

Notre lecture : à choix libre, PostgreSQL reste la cible par défaut pour un cœur applicatif. MySQL/MariaDB gagne quand l'environnement l'impose ou le favorise : hébergement mutualisé, application PHP existante, site WordPress adossé, équipe déjà à l'aise avec son administration.

Contraintes à connaître avant de choisir

• Activer le mode SQL strict dès le départ : par défaut historique, MySQL tolère des valeurs que la migration doit justement assainir.
• Choisir le jeu de caractères utf8mb4 systématiquement, pour couvrir tous les caractères sans surprise.
• Déclarer explicitement les contraintes d'intégrité référentielle (moteur InnoDB) : c'est elles qui révéleront les orphelins hérités de HFSQL.
• Vérifier la casse des noms de tables selon les systèmes de fichiers si les environnements mêlent Windows et Linux.

Points de vigilance à l'audit avant de choisir MySQL ou MariaDB

Avant d'arrêter le choix entre MySQL, MariaDB et PostgreSQL, l'audit vérifie plusieurs points spécifiques au futur environnement d'hébergement. La compatibilité de l'hébergement cible envisagé (mutualisé, infogéré, cloud) avec les versions récentes du moteur retenu. Le degré de dépendance de la future application aux extensions propres à PostgreSQL, qui pourrait faire pencher la balance si un existant les utilise déjà. Le bassin de compétences réellement disponible pour l'exploitation quotidienne de la base, souvent plus large côté MySQL dans les équipes orientées web. Et les exigences de conformité ou de sauvegarde propres au secteur d'activité, qui peuvent imposer des contraintes que tous les hébergeurs ne couvrent pas de la même façon selon le moteur choisi.

Méthode d'extraction et de chargement

La mécanique est la même que pour toute sortie de HFSQL : extraction (export ou programme dédié rejouable), dictionnaire de mapping des types documenté, nettoyage des données non conformes, chargement en masse (LOAD DATA INFILE) puis reconstruction des index. Le point propre à MySQL : verrouiller la configuration du serveur (mode strict, jeu de caractères, fuseaux) AVANT le premier chargement, pour que les rejeux soient strictement comparables d'un environnement à l'autre.

Adaptation des requêtes

Les requêtes issues de l'univers HFSQL se réécrivent en SQL standard, en privilégiant les opérations ensemblistes sur les parcours d'enregistrements. Les recherches insensibles à la casse et aux accents se règlent proprement par le choix des collations. Les traitements de dates et les agrégats financiers se testent en priorité : ce sont eux qui révèlent les écarts de comportement entre moteurs.

Erreurs fréquentes sur une migration vers MySQL ou MariaDB

• Laisser le mode SQL par défaut de l'hébergement sans le vérifier : un mode permissif accepte silencieusement des données que la migration était censée corriger, et le problème ne remonte que plus tard, en production.
• Choisir un jeu de caractères hérité au lieu d'utf8mb4 dès la création des tables : le corriger après coup impose de retoucher tout le schéma et de recharger les données.
• Ignorer les différences de comportement entre MySQL et MariaDB sur certaines fonctions avancées si le projet hésite encore entre les deux : mieux vaut trancher tôt plutôt que d'écrire un code qui suppose l'un et tourne sur l'autre.
• Négliger la casse des noms de tables et de colonnes quand les environnements de développement et de production ne tournent pas sur le même système d'exploitation : une requête qui fonctionne sous Windows peut échouer sous Linux.

Recette

Même exigence que pour toute reprise de données : comptages et agrégats comparés entre source et cible, échantillonnage des cas limites, rejeu complet à blanc avant bascule, et conservation de la base d'origine en lecture seule pendant la période de garantie. Une migration de base réussie est une migration ennuyeuse : tout a déjà été vu en répétition.