Faire évoluer un schéma sans douleur

Un schéma vit aussi longtemps que l'application : la question n'est pas « comment le créer » mais « comment le modifier sans interruption ».

Des migrations versionnées#

Chaque changement est un fichier de migration versionné, appliqué dans l'ordre par un outil (Flyway, Liquibase, dotnet ef, sqlx migrate, Atlas…), et jamais modifié une fois déployé.

Le patron expand / contract#

Pour renommer ou transformer une colonne sans coupure, on procède en plusieurs déploiements compatibles :

1. Expand : ajouter la nouvelle colonne (nullable) ; l'ancien code continue de fonctionner.
2. Le code écrit dans les deux colonnes, puis on remplit l'ancien historique par lots.
3. Le code lit la nouvelle colonne.
4. Contract : supprimer l'ancienne colonne, une fois plus aucun code ne l'utilise.

Piège : un ALTER TABLE ... RENAME COLUMN est instantané pour la base mais casse immédiatement le code déployé qui utilise l'ancien nom. Sur un système avec plusieurs instances ou des déploiements progressifs, le schéma doit toujours rester compatible avec la version précédente et la suivante du code.

Cas pratique : ajouter une colonne NOT NULL à une grande table : ajoutez-la d'abord nullable avec une valeur par défaut constante (instantané depuis PostgreSQL 11), remplissez l'existant par lots, puis posez la contrainte (voir « Migrations en ligne » dans le chapitre exploitation).