réalisation · Étude de cas

BddAdmin — Préparer les changements de base de données

Observer une base Oracle ou PostgreSQL, calculer les écarts avec la cible et examiner les opérations nécessaires à son évolution.

  • Contexte : Bibliothèque issue des besoins d’OSE
  • Période : Maintenu dans la durée
  • Données
  • Oracle
  • PostgreSQL
Schéma BddAdmin : comparer une base à sa référence pour préparer les opérations SQL

Le projet en bref

Le besoin
Préparer l’évolution d’une base réellement déployée vers une structure de référence.
Mon rôle
Architecte principal, développeur et mainteneur de la bibliothèque, issue en partie d’OSE.
La solution
Observer les objets, calculer les écarts et ordonner les transformations pour Oracle et PostgreSQL.
Résultat et état
Une bibliothèque qui produit un plan SQL examinable avant exécution, maintenue dans la durée. État documenté en juillet 2026.

Avant de modifier une base, comprendre ce qui va changer

Une mise à jour doit transformer la base réellement déployée, avec ses objets et ses dépendances. Préparer les bonnes opérations suppose de connaître les écarts avec l’état attendu.

J’ai porté l’architecture et le développement de BddAdmin pour observer cet état, calculer les différences et ordonner les transformations sur Oracle et PostgreSQL.

Le résultat : une bibliothèque qui produit les opérations SQL adaptées au moteur et permet de les examiner avant leur exécution. L’équipe technique peut partir des écarts observés pour préparer une évolution.

Un besoin issu de l’évolution des applications

Les besoins de déploiement et d’évolution d’OSE ont conduit à développer des mécanismes réutilisables autour des bases de données.

BddAdmin porte cette logique sur Oracle et PostgreSQL. Il rapproche une description de référence de l’état réel de la base et produit les opérations adaptées au moteur concerné.

Ma contribution

Je suis l’architecte principal, le développeur et le mainteneur de fait de BddAdmin. J’ai porté l’architecture de la bibliothèque, l’articulation entre Oracle et PostgreSQL, ses évolutions majeures, la documentation et les versions.

Une partie du code initial provient d’OSE. Cette origine fait partie de l’histoire de la bibliothèque et distingue mon travail d’évolution de l’attribution de chaque ligne antérieure.

Observer, comparer, préparer

Observer l’état réel

La bibliothèque lit les catalogues du moteur pour représenter les objets présents dans la base : tables, colonnes, contraintes, vues et autres éléments pris en charge.

Comparer avec une référence

Un modèle commun permet d’exprimer la cible et de calculer les différences. L’architecture partage ce travail de comparaison tout en conservant des traitements propres à chaque moteur.

Ordonner les transformations

Les dépendances comptent autant que les écarts. Certains objets doivent être retirés puis recréés dans un ordre adapté. Le plan tient aussi compte des étapes de préparation et de synchronisation.

Produire le SQL adapté

Des pilotes spécialisés génèrent les opérations pour Oracle ou PostgreSQL. La prévisualisation et l’exécution s’appuient sur le même chemin de traitement.

Prendre en compte les données, pas seulement leur structure

La convergence peut également concerner des données de référence. Un rapprochement par clé métier permet de déterminer les opérations nécessaires : insertion, mise à jour ou autres actions prévues par le traitement.

Cette approche oblige à expliciter ce qui identifie une donnée, ce qui peut changer et comment interpréter son absence.

Rendre les changements compréhensibles avant leur application

BddAdmin associe un modèle de données commun, l’introspection de deux moteurs, un calcul d’écarts et une orchestration des changements.

Cette organisation permet de distinguer l’observation, la comparaison et la transformation. Pour préparer une évolution, on peut examiner les écarts et les opérations nécessaires en tenant compte du moteur concerné.

Ce que cela apporte à une mission

Sur une migration ou une intégration, je cherche d’abord à rendre visibles l’état de départ, la cible et les règles du passage de l’un à l’autre.

Cette façon de travailler permet de discuter le plan, préparer les vérifications et identifier les points qui demandent un essai ou une décision. Les moyens de test et de reprise sont définis selon le projet.

Découvrir les prestations données et intégrations

Une évolution de base vous semble difficile à maîtriser ?

Présentez-moi les moteurs concernés, le changement envisagé et les dépendances que vous connaissez. Nous déterminerons les observations et les contrôles utiles avant d’intervenir.

Parlons de votre besoin · Revenir aux réalisations