KivTools

Générateur de modèles ORM depuis SQL

Collez les définitions de tables et choisissez l’ORM. Adaptez les types et le comportement propre à votre application avant d’utiliser l’ébauche.

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.
SQL DDLCollez des instructions CREATE TABLE de MySQL, PostgreSQL, SQLite ou SQL Server. L’analyseur lit les tables, les colonnes, les clés primaires et les clauses REFERENCES directes.
Modèles générés

Comment convertir des instructions CREATE TABLE en modèles ORM

Collez des instructions CREATE TABLE, choisissez Prisma, Drizzle, TypeORM ou SQLAlchemy, puis cliquez sur Générer des modèles. Chaque table du texte est lue — colonnes, types, NOT NULL, clés primaires, valeurs par défaut et clés étrangères — et le résultat contient un bloc de modèle par table, prêt à copier ou à télécharger.

Tout se passe dans la page : la génération n’a déclenché aucune requête réseau lors des tests, le schéma ne quitte donc pas le navigateur et l’outil continue de fonctionner quand la connexion tombe.

  1. Collez le DDL dans le champ DDL SQL, ou cliquez sur Charger un exemple pour partir de deux petites tables.
  2. Choisissez la cible dans Générer pour : Prisma, Drizzle ORM, TypeORM ou SQLAlchemy.
  3. Cliquez sur Générer des modèles. La ligne d’état indique combien de modèles de table ont été produits et signale toute définition du DDL collé qui n’a pas pu être lue.
  4. Changez de cible à tout moment : le résultat est régénéré et correspond donc toujours à l’ORM affiché à côté.
  5. Utilisez Copier ou Télécharger (models.ts, ou models.py pour SQLAlchemy) pour récupérer le code, et Effacer pour vider les deux champs. Si aucun CREATE TABLE n’est trouvé, le résultat est vidé et Copier indique qu’il n’y a rien à copier.

Comment le DDL est lu et ce que contiennent les modèles

Ce que lit l’analyseur

Les noms de tables, avec ou sans préfixe de schéma (app.accounts ressort en accounts), les noms de colonnes entre accents graves, guillemets doubles ou crochets, et le type de chaque colonne. NOT NULL rend un champ obligatoire, une colonne nullable reste optionnelle. Les clés primaires proviennent d’un PRIMARY KEY au niveau de la colonne et d’un PRIMARY KEY (a, b) au niveau de la table, clés composites comprises.

L’auto-incrément vient du DDL et non du nom de la colonne : SERIAL, BIGSERIAL, AUTO_INCREMENT, GENERATED … AS IDENTITY et une valeur par défaut nextval(…) sont reconnus, tandis qu’un simple PRIMARY KEY reste une clé ordinaire. DEFAULT CURRENT_TIMESTAMP et now() deviennent la valeur « now » propre à chaque cible. Les clés étrangères sont lues dans les REFERENCES au niveau de la colonne comme dans les clauses CONSTRAINT … FOREIGN KEY de la table. Les commentaires de ligne (-- et # de MySQL) et de bloc sont retirés avant l’analyse.

Ce que produit chaque cible

Prisma : un modèle par table avec @id, @@id([...]) lorsque la clé couvre plusieurs colonnes, @default(autoincrement()) uniquement là où le DDL le déclare, @default(now()) pour les horodatages courants, @db.Uuid pour les colonnes UUID et @map / @@map pour que les noms générés pointent toujours vers les noms SQL d’origine.

Drizzle ORM : des déclarations pgTable écrites pour le dialecte Postgres, avec primaryKey({ columns: [...] }) pour les clés composites. TypeORM : @PrimaryGeneratedColumn uniquement pour les colonnes auto-incrémentées et @PrimaryColumn pour toutes les autres clés, afin que les décorateurs correspondent au schéma. SQLAlchemy : des classes DeclarativeBase de style 2.0 avec annotations Mapped[...], mapped_column() et ForeignKey('table.colonne') pour les deux écritures de clé étrangère ; la liste des imports ne contient que ce que les modèles utilisent.

À vérifier avant de réutiliser le résultat

La correspondance des types est volontairement grossière. varchar, char, text et citext deviennent le type chaîne de la cible, DECIMAL et NUMERIC une colonne décimale annotée Decimal, JSON, JSONB et XML le type JSON générique, et tout type inconnu retombe sur string. Comparez une table représentative avec le schéma réel avant de générer des migrations à partir du résultat.

Tout ce qui n’est pas une colonne reste dans la base : CHECK, UNIQUE, index, vues, déclencheurs, séquences, collations et clauses de stockage ne sont pas convertis, et aucune cible ne reçoit de propriétés de relation ou de navigation — une clé étrangère reste une colonne simple partout, sauf en SQLAlchemy où ForeignKey est ajouté. La sortie Drizzle reste en dialecte Postgres, quel que soit le dialecte du DDL collé.

Outils récents :