En informatique, un projet de migration consiste à changer un ou plusieurs
composants techniques sans qu’aucun comportement des applications n’en soit
impacté. Dans le paysage des bases de données (et le métier que j’exerce), il
s’agira de choisir un nouveau système (comme PostgreSQL) en remplacement d’un
autre (comme Oracle ou Microsoft SQL Server).
Dans un précédent article, je décrivais les étapes exhaustives pour
réaliser une migration complète à l’aide de la technologie des Foreign Data
Wrappers, mais l’étape critique de transfert des données qui y était décrite ne
s’adapte pas à toutes les situations. Voyons ensemble les alternatives qui
permettent de couvrir une grande partie des besoins.
J’ai passé plusieurs semaines ces derniers mois à contribuer à l’extension
db_migrator. Rédigée uniquement en PL/pgSQL, elle permet de migrer les schémas
et les données d’un système de bases de données vers PostgreSQL à l’aide des
données externes que j’avais déjà présentées il y a quelques années.
Dans cet article, je présente le fonctionnement de l’outil, sa philosophie et la
raison d’être que je lui ai trouvée, alors même qu’il rejoint l’écosystème des
projets libres déjà bien installés dans le paysage de la migration. Que vaut-il
aux côtés d’Ora2Pg ou de pgloader ?
La norme ISO SQL/Foundation (ISO/IEC 9075-2:2016) fait partie du standard
SQL et définit les règles pour la définition des relations et la manipulation
des données. En adoptant cette norme, les moteurs de bases de données
garantissent une interopérabilité avec leurs concurrents et permettent aux
entreprises de bénéficier d’une plus grande flexibilité lorsqu’elles souhaitent
passer de l’un à l’autre sans (trop) réécrire leur modèle de données ou leurs
requêtes SQL.
Dans sa publication SQL:2003, la norme a introduit le concept de colonnes
générées comme nouvelle spécification technique. Parfois appelées colonnes
calculées ou colonnes virtuelles, leurs valeurs dérivent de celles des autres
colonnes de la table. Un des articles de Markus Winand passe au crible les
différents systèmes du marché pour voir s’ils respectent ce standard.
PostgreSQL propose un certain nombre de fonctions qui permettent de calculer des
valeurs agrégées ou relatives sur un ensemble de lignes qui se situent dans une
« fenêtre » autour de la ligne courante. En utilisant de telles fonctions,
n’importe qui peut créer des requêtes plus avancées et plus efficaces pour
l’analyse de leur base de données.
Depuis plusieurs semaines, je contribue à un projet de conversion de modèles de
données vers PostgreSQL, appelé db_migrator. À cette occasion, j’ai
(re)découvert la puissance de ces fonctions de fenêtrage avec le langage
SQL. Dans cet article, je reviens sur un cas concret de transformation des
bornes supérieures d’une table partitionnée en tableau de valeur.
Alors que la version 15 de PostgreSQL se prépare à sortir dans les prochains
jours, le groupe de développement du projet communautaire ont intégré leurs
récents travaux pour accélérer les tâches d’automatisation et de compilation
à l’aide du système de construction Meson.
Ce chantier n’est pas anodin et redessine les contours de l’écosystème du moteur
de bases de données open-source le plus avancé au monde. Depuis sa forme libre
publiée en 1998, PostgreSQL repose sur des solutions robustes et éprouvées, mais
de plus en plus complexes à maintenir pour les nouvelles générations de
contributeur·rices. En proposant de se tourner vers un logiciel comme Meson, ces
amoureux et amoureuses du libre se tournent résolument vers l’avenir.