Lécluse.netFaire évoluer une base de données : examiner avant d’exécuter
Blog · Laurent Lécluse · 5 septembre 2026
Un script de mise à jour décrit des opérations à effectuer. Encore faut-il savoir si elles correspondent à la base sur laquelle on va les appliquer : les versions installées, les objets présents et les données peuvent différer de ce que l’on attend.
J’ai porté l’architecture et le développement de BddAdmin pour observer des bases Oracle et PostgreSQL, calculer les écarts avec une référence et préparer les opérations de transformation. Cette expérience nourrit ma façon d’aborder les évolutions de données.
Observer ce qui existe réellement
Le point de départ est la base déployée : ses tables, ses colonnes, ses contraintes, ses vues et les autres objets concernés par le changement.
Une description conservée dans le projet reste utile pour connaître l’intention. L’observation de la base permet de la confronter à la réalité. C’est notamment le rôle de l’introspection : lire les informations que le moteur expose sur sa propre structure.
Définir une cible que l’on peut comparer
Une fois l’état actuel représenté, il faut décrire l’état attendu. La comparaison permet de distinguer les objets à créer, ceux à modifier et ceux dont la présence doit être examinée.
Avec BddAdmin, une représentation commune porte une partie de cette comparaison, tandis que des traitements spécialisés prennent en compte Oracle et PostgreSQL. Partager une logique d’analyse demande de conserver les différences utiles entre les moteurs.
Un exemple : rendre une information obligatoire
Prenons un exemple pédagogique : une application doit désormais exiger un code sur chaque dossier. Le changement semble se résumer à l’ajout d’une contrainte. Mais il pose plusieurs questions :
- Des dossiers existants n’ont-ils aucun code ?
- Peut-on retrouver l’information manquante de manière fiable ?
- Faut-il une correction par un utilisateur ?
- L’application est-elle prête à renseigner ce code lors de chaque création ?
L’ordre des opérations dépend des réponses. Préparer les données, adapter l’application et activer la contrainte peuvent former plusieurs étapes distinctes.
Examiner les dépendances et l’ordre des opérations
Une modification peut concerner une colonne utilisée par une vue, une contrainte ou un autre traitement. Les écarts structurels ne suffisent donc pas à définir l’ordre d’exécution.
Je cherche à rendre cet ordre visible dans le plan : quelles opérations préparent les suivantes, lesquelles transforment les données et lesquelles établissent l’état final attendu ?
BddAdmin produit des opérations SQL adaptées au moteur et permet de les examiner avant leur exécution. Cette visibilité aide à discuter et à vérifier le changement envisagé.
Vérifier les données autant que la structure
Une base peut présenter la structure attendue tout en contenant des informations mal reprises. Les contrôles doivent aussi porter sur le sens des données : relations conservées, valeurs obligatoires renseignées, données de référence correctement rapprochées.
Selon le changement, je prépare des vérifications ciblées : comparer un total, examiner des dossiers représentatifs ou contrôler les relations concernées. Les critères doivent être définis à partir de ce que l’application et ses utilisateurs ont besoin de retrouver.
Préparer les conditions d’application
Le plan technique s’inscrit dans une intervention : environnement d’essai, sauvegarde et restauration, disponibilité de l’application, personnes chargées de la validation. Ces conditions sont à préciser avant le passage sur les données utilisées au quotidien.
Le travail préparatoire doit permettre de répondre à trois questions : qu’allons-nous changer, comment saurons-nous que le résultat convient, et que ferons-nous si une étape échoue ?
Vous préparez une migration ou une évolution qui touche vos données ? Nous pouvons commencer par comparer l’état actuel et la cible, puis définir les opérations et les contrôles nécessaires.
Découvrir les prestations données et intégrations · Parlons de votre projet