KivTools

Comparaison de schémas SQL et brouillon de migration

Collez les schémas avant et après, puis choisissez le dialecte. Relisez le SQL produit : les suppressions de tables et de colonnes sont commentées et les autres instructions doivent être vérifiées avant exécution.

Fonctionne localement dans votre navigateur
Voir la catégorie: SQL et bases de données (12)
Tout dans cet outil est traité dans ce navigateur. KivTools ne télécharge pas, ne stocke pas et n’appelle aucune API tierce avec votre entrée.
Instantanés de schémaCollez l'ancien et le nouveau CREATE TABLE SQL.
Projet de migrationLes actions destructrices sont commentées pour examen.
Exécutez l'outil pour voir la sortie locale ici.

Comment comparer deux instantanés de schéma et préparer une migration

Collez l’ancien schéma dans Before et le nouveau dans After, choisissez PostgreSQL ou MySQL, puis lancez Générer une migration. L’outil lit les instructions CREATE TABLE et écrit les instructions ALTER et CREATE qui font passer d’un instantané à l’autre.

Tout s’exécute dans le navigateur ; aucun texte de schéma ne quitte la page. Le résultat est un brouillon à relire : les instructions qui peuvent détruire des données sont écrites en commentaire pour que rien ne s’exécute par accident.

  1. Collez le schéma actuel dans Before, ou récupérez-le avec un dump de schéma seul (pg_dump --schema-only ou mysqldump --no-data).
  2. Collez le schéma cible dans After, ou relancez ce dump après la modification à appliquer.
  3. Choisissez le dialecte du serveur qui exécutera la migration, puis lancez Générer une migration.
  4. Lisez d’abord la liste des constats : ajouts, modifications et éléments destructeurs sont séparés, et les instructions destructrices restent commentées dans le brouillon.
  5. Copiez ou téléchargez schema-migration.sql, exécutez-le sur une copie de recette dans une transaction quand le moteur le permet, puis seulement en production.

Ce que couvre le brouillon, ce qui reste commenté et ce qui est ignoré

Ce que le brouillon détecte

Il compare les tables et les colonnes : tables et colonnes ajoutées ou supprimées, changements de type, changements de NOT NULL et changements de valeur par défaut. Les clés primaires ajoutées, supprimées ou portant sur d’autres colonnes sont signalées aussi, y compris les définitions au niveau table comme PRIMARY KEY (a, b).

Les clés étrangères sont comparées qu’elles soient écrites sur la colonne (REFERENCES users(id)) ou comme contrainte de table (FOREIGN KEY (a, b) REFERENCES parent (x, y)). Une clé ajoutée devient ADD CONSTRAINT, une clé supprimée reste commentée avec le nom de contrainte que l’outil utiliserait.

Ce qui reste commenté et ce qui est ignoré

DROP TABLE, DROP COLUMN et les clés primaires ou étrangères supprimées sont imprimés en commentaire sous un repère DESTRUCTIVE, car ils suppriment des données ou des contraintes qu’une nouvelle exécution ne peut pas restaurer. Cette page n’exécute jamais le brouillon : c’est vous qui activez les lignes.

Seules les instructions CREATE TABLE sont lues. Les définitions UNIQUE, CHECK et INDEX ne sont pas comparées, et les changements de données, renommages, vues, séquences, déclencheurs, droits et options de table propres au moteur sont hors périmètre. Quand ces définitions sont ignorées, le brouillon le signale au lieu d’afficher un diff propre.

Exécuter le brouillon en sécurité

Testez d’abord sur une copie de recette et générez le schéma avec un dump de schéma seul pour que les données ne masquent pas le diff. PostgreSQL exécute presque tout le DDL dans une transaction : BEGIN et ROLLBACK peuvent annuler une migration erronée ; MySQL valide le DDL de façon implicite, une erreur doit donc être corrigée en avançant.

Ajouter NOT NULL ou une clé primaire valide ou réécrit une table existante et peut la verrouiller pendant l’opération. Vérifiez la durée sur la taille réelle de la table (PostgreSQL valide NOT NULL par un parcours complet, MySQL peut reconstruire la table) et planifiez la modification plutôt que de la lancer en pleine charge.

Outils récents :