Migrez HFSQL comme un programme à part entière — pas comme un à-côté de la réécriture.
La modernisation applicative et la modernisation des données sont liées, mais elles n'ont pas besoin d'avoir lieu au même moment. Traitez la base de données comme un programme maîtrisé, avec son propre inventaire, son propre choix de cible et son propre test d'acceptation — et la réécriture devient plus facile à faire confiance.
Pourquoi ne pas migrer les deux en même temps
- Chaque défaut devient ambigu. Déplacez l'application et la base ensemble, et un écran cassé peut venir du code converti, de la sémantique SQL, de la transformation des données ou de l'infrastructure — vous ne saurez pas quoi.
- Le système existant a besoin d'un sol stable. Convertissez d'abord le schéma à l'identique, et votre application WinDev existante continue de tourner sur les mêmes données pendant que la réécriture avance.
- La réconciliation exige une cible stable. Vous ne pouvez pas prouver que les nombres de lignes et les totaux de contrôle correspondent si le schéma change aussi de forme en dessous.
- La base de données cible est une décision séparée. PostgreSQL, SQL Server ou MySQL doivent être choisis en fonction des besoins futurs du produit — pas selon le mapping le plus facile à automatiser.
Ce qu'il faut inventorier avant de toucher une seule colonne
- Tables, clés et contraintes. L'ossature structurelle, capturée avant que quoi que ce soit ne soit réécrit.
- Requêtes intégrées dans les écrans, rapports et procédures. Une logique HFSQL qui n'a jamais vécu à un seul endroit évident.
- Procédures stockées et déclencheurs. Un comportement côté serveur dont il faut tenir compte, pas seulement du schéma.
- Blobs, hypothèses de système de fichiers et précision numérique. Pièces jointes, jeux de caractères, dates et gestion des null — les détails qui font échouer la réconciliation plus tard.
- Concurrence et comportement transactionnel. Comment HFSQL gère réellement le verrouillage aujourd'hui, pour que la base cible puisse être configurée pour correspondre.
Choisir la base de données cible
PostgreSQL
Une stack ouverte avec de solides capacités SQL — le choix par défaut quand rien ne justifie de rester centré Microsoft.
SQL Server
Un choix naturel pour les organisations déjà standardisées sur l'infrastructure et les licences Microsoft.
MySQL
Pratique pour des produits web largement hébergés, où l'écosystème l'attend déjà.
Le choix doit venir des besoins futurs du produit, pas du convertisseur pour qui le mapping de types est le plus simple.
La réconciliation est le test d'acceptation
Ce qui est vérifié : Nombres de lignes, totaux de clés, totaux de contrôle quand ils s'appliquent, relations orphelines, comportement des null et de la précision, et résultats de requêtes représentatives — face à la charge réelle, pas des insertions synthétiques.
Comment les jalons basculent : Les jalons applicatifs migrés continuent d'utiliser le contrat de données établi pendant que la nouvelle persistance est préparée, puis un domaine délimité bascule — votre système existant continuant de tourner sur les mêmes données tant que nécessaire.
Les questions que se posent les développeurs en premier
Non — le schéma est converti à l'identique en premier, précisément pour que votre système existant continue de tourner sans changement pendant que la migration applicative suit son propre calendrier.
Vous, en fonction des besoins futurs du produit. WXCode n'impose pas un choix par défaut pour simplifier sa propre conversion.
Par réconciliation des nombres de lignes, des totaux de contrôle et des résultats de requêtes représentatives — les mêmes vérifications qu'utilise un programme de données maîtrisé, pas un simple sondage.
Guides associés
Testez-le sur votre vrai projet.
Commencez par la base de connaissances, les dépendances et les règles métier — avant de vous engager dans une réécriture.