Réponse.

Historique de la question

Le changement de schéma de table est devenu pertinent avec la large adoption des méthodologies Agile. Les projets évoluent, les exigences changent — au fil du temps, il est inévitable qu'il y ait besoin d'ajouter/ modifier/ supprimer des colonnes. Dans les bases de données en production, de tels changements sont particulièrement risqués.

Problème

La modification de la structure peut entraîner :

des blocages de longue durée
la perte de données anciennes ou une migration incorrecte
la violation de contraintes externes, de déclencheurs ou de la logique de l'application

Les changements dans de grandes tables (millions de lignes), qui sont activement utilisées par d'autres services, sont particulièrement complexes.

Solution

Un travail compétent via ALTER TABLE — des modifications par étapes, création d'une copie des données, tests sur un environnement de mise en scène, limitation du temps d'arrêt. Utilisation de transactions, migration par étapes et sauvegarde avant de grands changements. Dans des bases de données très sollicitées, il est fréquent d'utiliser des algorithmes ALTER "en ligne".

Exemple de code :

-- Ajout d'une nouvelle colonne avec une valeur par défaut
ALTER TABLE orders ADD COLUMN status VARCHAR(20) DEFAULT 'new';

-- Remplissage progressif des nouvelles colonnes
UPDATE orders SET status = CASE WHEN shipped_at IS NOT NULL THEN 'shipped' ELSE 'pending' END;

Caractéristiques clés :

Il est préférable de créer d'abord de nouvelles colonnes, puis de transférer progressivement les données
Réaliser de grandes opérations en dehors des heures de pointe
Toujours faire des sauvegardes et des tests automatiques

Questions pièges.

L'ALTER TABLE est-il exécuté de manière atomique ?

Le plus souvent non : le changement de table peut prendre beaucoup de temps. En cas d'échec, certaines modifications peuvent être annulées, mais d'autres peuvent rester en suspens. C'est pourquoi la protection transactionnelle pour les commandes DDL n'est mise en œuvre que par certaines SGBD (par exemple, PostgreSQL).

Peut-on changer le type d'une colonne de INTEGER à VARCHAR sans douleur ?

Pas toujours : si la colonne contient des données anciennes qui ne correspondent pas au nouveau format, ou des objets liés (index, déclencheurs, clés), la SGBD pourrait ne pas autoriser la modification du type ou les données pourraient être corrompues.

L'ALTER TABLE impose-t-il toujours un verrou exclusif sur toute la table ?

Cela dépend de la SGBD : dans MySQL et les anciennes versions de SQL Server, toute opération ALTER bloque souvent complètement la table jusqu'à son achèvement, mais les SGBD modernes prennent en charge "DDL en ligne", réduisant ainsi le temps de blocage.

Erreurs typiques et anti-modèles

Modification de la structure sans sauvegarde
Migration de grandes tables sans test en mise en scène
Renommage de colonnes sans vérification des dépendances (par exemple, clés étrangères, procédures)
ALTER massif pendant les heures de pointe

Exemple de la vie

Cas négatif

Un ingénieur DevOps a effectué des modifications massives sur trois tables importantes via ALTER TABLE et a supprimé des colonnes anciennes. Il n'a pas pris en compte que ces colonnes étaient liées à des clés étrangères et des déclencheurs. Pendant que l'ALTER était en cours, la base était occupée pendant 20 minutes - pendant ce temps, les services ont "échoué" en raison de l'absence de champs nécessaires.

Avantages :

Les modifications ont été réalisées selon le cahier des charges

Inconvénients :

Perte de fonctionnalité d'une partie des services
Temps d'arrêt des affaires pendant presque une demi-heure
Récupération laborieuse des dépendances et retour des données supprimées

Cas positif

Un analyste a planifié l'ajout d'une colonne en plusieurs étapes : d'abord, une colonne avec une valeur par défaut a été créée, une charge de test a été injectée sur des copies, puis l'ALTER réel a été effectué la nuit et tous les développeurs ont été informés de la prochaine période de migration.