Le PG Day France s’est tenu les 11 et 12 juin derniers à Lille, ma ville natale.
Il s’agit de l’événement de la communauté française de PostgreSQL qui pose ses valises dans une
ville différente chaque année. L’occasion était trop belle pour moi et j’y ai rencontré de nombreuses
personnes venant de toute la France et de ses alentours, pour discuter de PostgreSQL au cours
de deux jours d’ateliers et de conférences.
Pour cette édition, j’ai eu le plaisir de prendre la parole et de faire un retour d’expérience
sur l’animation du groupe Meetup local dont j’ai repris les rennes il y a maintenant quatre ans.
Dans cet article, je souhaite retranscrire les principaux points abordés lors de cette présentation,
en attendant que la vidéo de la conférence soit mise en ligne.
Lors de la dernière PGSession 16, j’ai rédigé et animé un atelier de
trois heures au sujet de la migration vers PostgreSQL à l’aide des Foreign Data
Wrappers, ou FDW. Ce fut notamment l’occasion de présenter au grand public,
l’extension db_migrator pour laquelle j’ai dédié un article sur ce
blog.
Au cours de cet atelier, nous pouvons constater que la copie des données avec
l’extension db_migrator n’est pas parfaitement prise en charge. En effet, bien
qu’il existe une fonction de bas niveau pour répartir sur plusieurs processus le
transfert table à table, de nombreuses situations devront exiger de rédiger un
grand nombre de requêtes SQL pour se tirer d’affaire. Au cours des mois qui
suivirent, je me suis attelé à la conception d’un assistant écrit en
PL/pgSQL dont le but est de simplifier la génération de ces requêtes.
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.