Modifier le schéma sans casser les applications

Une migration de schéma peut réussir alors que l'application échoue. Pendant un déploiement progressif, anciennes et nouvelles versions partagent souvent la base. Renommer immédiatement une colonne ou rendre un champ obligatoire peut casser les processus encore actifs. L'unité réelle de déploiement est le contrat entre code et données.

Étendre avant de contraindre

Ajoutez une structure compatible, déployez un code comprenant les deux formes, reprenez les données historiques, vérifiez puis retirez l'ancien contrat plus tard. Une colonne nullable est souvent un bon départ, mais nécessite toujours des verrous de schéma. Une petite modification de métadonnées ne garantit pas l'absence de blocage.

L'exercice utilise une petite table temporaire. Exécutez les blocs dans l'ordre. Le passage à NOT NULL représente une étape distincte de validation, pas une action automatique immédiatement après l'ajout.

CREATE TABLE #Orders(OrderId int PRIMARY KEY, Amount decimal(12,2));
INSERT #Orders VALUES(1,10),(2,20);
ALTER TABLE #Orders ADD CurrencyCode char(3) NULL;

UPDATE #Orders SET CurrencyCode='USD' WHERE CurrencyCode IS NULL;
SELECT OrderId,Amount,CurrencyCode FROM #Orders ORDER BY OrderId;

IF EXISTS(SELECT 1 FROM #Orders WHERE CurrencyCode IS NULL)
    THROW 50000, 'Backfill is incomplete.', 1;
ALTER TABLE #Orders ALTER COLUMN CurrencyCode char(3) NOT NULL;

En production, définissez comment les nouvelles écritures renseignent CurrencyCode avant de terminer la reprise. USD n'est correct ici que parce que c'est le sens déclaré des données d'exercice. Une valeur pratique ne remplace pas la recherche de la vraie devise historique. Les inconnues doivent être rapprochées.

Organiser la coexistence

Si deux représentations coexistent, précisez laquelle fait autorité à chaque étape. Les doubles écritures doivent être atomiques ou réconciliées. Sinon un échec peut n'en modifier qu'une. Une lecture de secours peut maintenir le service tout en cachant une divergence ; mesurez explicitement les écarts avant de basculer les lecteurs.

Pour une grande table, utilisez des lots reprenables et une plage de clés stable. Le prédicat ne doit pas écraser des valeurs applicatives plus récentes. Validez le progrès avec les modifications lorsque sa persistance est nécessaire. Limiter les lignes modifiées ne limite pas automatiquement les lectures ou le journal produit par triggers et index.

Les modifications de schéma peuvent attendre derrière des transactions longues. Fixez un délai et une politique de reprise adaptés, inspectez les bloqueurs et ne relancez pas une migration tant que la précédente attend encore. Les possibilités online dépendent de l'opération, de la version et de l'édition ; elles ne suppriment pas tous les verrous.

Définir le retour arrière

Avant suppression, vérifiez qu'aucune version supportée, aucun rapport, job, export ou SQL dynamique ne dépend de l'ancien champ. Les catalogues aident mais ne voient pas toutes les chaînes construites hors de la base. Complétez l'inventaire par l'activité observée et des essais avec versions mélangées.

Revenir au code précédent n'est simple que si la base respecte encore son contrat. Si de nouvelles valeurs ne sont pas exprimables dans l'ancien modèle, le retour peut perdre du sens même lorsque la colonne existe. Documentez la dernière étape réversible et la récupération préservant les données après cette limite.

Vérifiez valeurs transformées, contraintes et lectures/écritures représentatives des deux versions, pas seulement les comptes. Interrompez la reprise et testez sa continuation. Conservez identifiants et état des migrations pour reconnaître le travail déjà appliqué.

La suppression finale doit être une livraison distincte après stabilité démontrée. Chaque étape reste alors explicable : qui peut lire, qui peut écrire, quelle représentation est correcte et quel retour reste possible sans perte.

Références techniques: Microsoft Learn: ALTER TABLE · Microsoft Learn: Dependency metadata.