Générateur de migrations de base de données — différence de schémas en SQL up / down
Générateur de migrations de base de données
Collez le schéma actuel à gauche et le schéma cible à droite — soit sous forme de DDL CREATE TABLE, soit sous forme de JSON de schéma issu du Concepteur ERD — puis générez un script d’avancement (up) et le script de retour arrière correspondant (down) : tables créées et supprimées, colonnes ajoutées, retirées et modifiées, et modifications des clés étrangères, mises entre guillemets pour MySQL, PostgreSQL, SQL Server, SQLite, Oracle ou le SQL standard. Rien n’est envoyé ; la comparaison s’exécute dans votre navigateur.
1 — Avant (schéma actuel)
2 — Après (schéma cible)
3 — Générer la migration
Les instructions sont regroupées par table — relisez la sortie avant de l’exécuter.
Aucune comparaison générée pour l’instant.
Périmètre : il s’agit d’une comparaison structurelle des tables, colonnes, clés primaires, nullabilité, valeurs par défaut et clés étrangères. Les index, déclencheurs, vues et rattrapages de données sont hors périmètre et doivent être ajoutés à la main. SQLite ne peut pas modifier une colonne sur place : ces modifications sont donc émises sous forme de commentaire vous demandant de recréer la table.
Qu’est-ce qu’une migration de base de données ?
Une migration est un script versionné qui modifie le schéma d’une base : créer telle table, ajouter telle colonne, supprimer tel index. Les équipes appliquent les migrations dans l’ordre afin que chaque environnement — développement, préproduction, production — suive le même chemin de version en version, au lieu d’être retouché à la main vers des structures qui ne correspondent plus au code. Chaque migration se compose généralement de deux moitiés : up applique la modification, down l’annule, afin qu’une mauvaise version puisse être annulée de la même manière qu’elle a été appliquée.
Les migrations qui suppriment des tables ou des colonnes sont destructrices — le script down ne peut pas restaurer les données supprimées. Sauvegardez (ou au moins exportez les tables concernées) avant d’exécuter une migration qui supprime quoi que ce soit.
