Modifications Additives de Base de Données : Comment Ajouter Sans Casser la Production
Vous avez une application en production avec des milliers d'utilisateurs actifs. Votre équipe doit ajouter un champ numéro de téléphone au profil utilisateur. La modification semble mineure, mais l'idée d'exécuter un ALTER TABLE sur une base de données de production rend tout le monde nerveux. Et si la migration verrouille la table ? Et si l'ancien code applicatif plante parce qu'il ne s'attend pas à la nouvelle colonne ?
Cette situation se produit dans presque toutes les équipes d'ingénierie qui gèrent leur propre base de données. La bonne nouvelle est qu'une catégorie de modifications de schéma est remarquablement sûre, même sous charge de production. Comprendre cette catégorie change la façon dont vous planifiez les déploiements, dont vous coordonnez votre équipe et le niveau de risque que vous prenez en faisant évoluer votre base de données.
Ce Qui Rend une Modification Additive
Une modification additive est toute modification qui ajoute uniquement quelque chose de nouveau au schéma de base de données sans altérer ni supprimer ce qui existe déjà. La liste est simple :
- Ajouter une nouvelle colonne à une table existante
- Créer une nouvelle table
- Ajouter un nouvel index
- Ajouter une contrainte qui ne restreint pas les données existantes
La propriété clé est que vous étendez le schéma. Vous ne renommez pas de colonnes, ne changez pas de types de données, ne fusionnez pas de tables et ne supprimez rien. Les anciennes parties du schéma restent exactement comme elles étaient.
Pourquoi les Modifications Additives Sont Sûres
La sécurité vient d'un fait simple : l'ancien code applicatif ne dépend pas de ce que vous venez d'ajouter. Lorsque vous ajoutez une colonne phone à la table users, le code applicatif existant continue de lire et d'écrire name, email et password exactement comme avant. Il n'a aucune idée qu'une nouvelle colonne existe. Il n'essaie pas de la lire, ni d'y écrire. Rien ne casse.
Ce n'est pas vrai pour d'autres types de modifications. Si vous renommez une colonne de phone à phone_number, l'ancien code applicatif essaiera de lire phone et échouera car cette colonne n'existe plus. Si vous changez un type de colonne de VARCHAR à INT, l'ancien code pourrait écrire une valeur chaîne que la base de données ne peut plus accepter. Si vous fusionnez deux tables, les anciennes requêtes qui référencent la structure de table d'origine planteront.
Les modifications additives évitent tous ces problèmes car elles ne touchent à rien de ce dont l'ancien code dépend.
La Règle Critique Unique
Il y a une condition qui rend les modifications additives sûres : la nouvelle colonne doit être nullable ou avoir une valeur par défaut.
Si vous ajoutez une colonne avec NOT NULL et sans valeur par défaut, chaque ligne existante dans la table violera immédiatement la contrainte. La base de données rejettera la migration. Dans le pire des cas, la migration s'exécute partiellement, réussit pour certaines lignes, puis échoue, vous laissant avec des données incohérentes difficiles à nettoyer.
Le modèle standard ressemble à ceci :
ALTER TABLE users ADD COLUMN phone VARCHAR(20) NULL;
Si vous savez que la colonne sera éventuellement obligatoire, ajoutez d'abord une valeur par défaut :
ALTER TABLE users ADD COLUMN phone VARCHAR(20) NOT NULL DEFAULT '';
Avec une valeur par défaut, chaque ligne existante reçoit une chaîne vide. L'ancien code applicatif peut toujours lire cette colonne sans erreur. Plus tard, après que toutes les instances applicatives ont été mises à jour pour gérer correctement la nouvelle colonne, vous pouvez supprimer la valeur par défaut ou ajouter une contrainte NOT NULL dans une migration séparée.
Exécuter des Modifications Additives Pendant les Heures de Production
L'un des plus grands avantages pratiques des modifications additives est que vous pouvez les exécuter pendant que la production est active. Dans la plupart des bases de données modernes, ALTER TABLE ADD COLUMN avec une colonne nullable est une opération légère qui ne verrouille pas la table pendant une période prolongée.
Il existe des exceptions. Les anciennes versions de MySQL peuvent verrouiller la table pendant un ALTER TABLE. Ajouter une colonne à une position spécifique avec AFTER peut également provoquer plus de verrouillage que l'ajout à la fin. Mais en général, ajouter une colonne nullable est l'une des opérations les plus sûres que vous puissiez effectuer sur une base de données en direct.
Cela signifie que vous n'avez pas besoin d'une fenêtre de maintenance. Vous n'avez pas besoin d'attendre les heures de faible trafic. Vous pouvez exécuter la migration pendant la journée, vérifier qu'elle fonctionne et passer à l'étape suivante de votre déploiement.
Comment Cela Permet des Déploiements Progressifs
Les modifications additives débloquent une stratégie de déploiement difficile à réaliser avec d'autres types de modifications de schéma : les mises à jour progressives sans coordination.
Imaginez que vous avez dix instances applicatives derrière un équilibreur de charge. Vous voulez déployer une nouvelle version qui lit et écrit la colonne phone. Voici comment le processus fonctionne :
- Exécutez la migration pour ajouter la colonne
phone. Le schéma a maintenant la nouvelle colonne, mais les dix instances exécutent toujours l'ancien code qui l'ignore. - Mettez à jour une instance vers le nouveau code. Cette instance commence à lire et écrire la colonne
phone. Les neuf autres instances continuent de fonctionner normalement car elles ne touchent jamais à la nouvelle colonne. - Mettez progressivement à jour les instances restantes une par une. À tout moment de ce processus, les instances anciennes et nouvelles coexistent sans conflit.
Cela n'est possible que parce que la modification du schéma est additive. Si la modification nécessitait de supprimer une colonne ou d'en renommer une, les anciennes instances planteraient dès l'exécution de la migration. Vous seriez obligé de mettre à jour toutes les instances à la fois, ce qui augmente le risque et nécessite une coordination minutieuse.
Quand Aller Au-Delà des Modifications Additives
Les modifications additives sont sûres, mais elles ne sont pas toujours suffisantes. Finalement, vous aurez besoin de supprimer des colonnes inutilisées, de changer des types de données pour résoudre des problèmes de performance, ou de restructurer des tables pour prendre en charge de nouvelles fonctionnalités. Ces changements comportent plus de risques et nécessitent des stratégies différentes.
La séquence pratique est : commencez par des modifications additives pour introduire de nouvelles colonnes et tables, laissez le code applicatif rattraper son retard, puis planifiez les modifications plus invasives dans des migrations séparées. Chaque migration doit faire une chose et une seule. Ne mélangez pas une modification additive avec une modification destructive dans le même script de migration.
Une Liste de Vérification Rapide pour les Modifications Additives
Avant d'exécuter une modification additive en production, passez en revue ces vérifications :
- La nouvelle colonne est-elle nullable ou a-t-elle une valeur par défaut ?
- La migration ajoute-t-elle uniquement des éléments, sans modifier ni supprimer le schéma existant ?
- Avez-vous testé la migration sur une copie des données de production ?
- Avez-vous un plan de retour arrière ? (Pour les modifications additives, le retour est généralement
ALTER TABLE DROP COLUMN, mais vérifiez que cela fonctionne.) - L'ancien code applicatif peut-il toujours s'exécuter sans modification après la migration ?
Si vous pouvez répondre oui à toutes ces questions, vous êtes prêt à exécuter la migration en toute confiance.
L'Essentiel à Retenir
Les modifications additives sont la catégorie la plus sûre des modifications de schéma de base de données car elles étendent le schéma sans rien casser de ce dont l'ancien code dépend. Utilisez des colonnes nullables ou des valeurs par défaut, exécutez-les pendant les heures normales et déployez vos instances applicatives progressivement. Cette approche supprime la tension entre faire évoluer votre base de données et maintenir la production stable. Commencez chaque modification de schéma en vous demandant : puis-je la rendre additive ? Si oui, faites cela d'abord. Réservez les modifications plus risquées pour plus tard, lorsque le nouveau schéma est déjà utilisé et que l'ancien code a été retiré.