VoriTools

Generador de modelos ORM desde SQL

Pega las tablas y elige el ORM. Copia el borrador y adapta los tipos y el comportamiento propio de tu aplicación antes de usarlo.

Se ejecuta localmente en tu navegador
Ver categoría: SQL y bases de datos (12)
Esta herramienta procesa todos los datos localmente en tu navegador.
DDL SQLPega instrucciones CREATE TABLE de MySQL, PostgreSQL, SQLite o SQL Server. El analizador lee tablas, columnas, claves primarias y cláusulas REFERENCES directas.
Modelos generados

Cómo convertir instrucciones CREATE TABLE en modelos ORM

Pega instrucciones CREATE TABLE, elige Prisma, Drizzle, TypeORM o SQLAlchemy y pulsa Generar modelos. Se lee cada tabla del texto —columnas, tipos, NOT NULL, claves primarias, valores por defecto y claves externas— y se devuelve un bloque de modelo por tabla, listo para copiar o descargar.

Todo ocurre en la página: al generar los modelos no se envió ninguna petición de red en las pruebas, así que el esquema no sale del navegador y la herramienta sigue funcionando cuando se cae la conexión.

  1. Pega el DDL en el panel DDL SQL o pulsa Cargar ejemplo para partir de dos tablas pequeñas.
  2. Elige el destino en Generar para: Prisma, Drizzle ORM, TypeORM o SQLAlchemy.
  3. Pulsa Generar modelos. La línea de estado indica cuántos modelos de tabla se crearon y avisa cuando una definición del DDL pegado no se ha podido leer.
  4. Cambia el destino cuando quieras: el panel se regenera, así que el código siempre corresponde al ORM que aparece junto a él.
  5. Usa Copiar o Descargar (models.ts, o models.py para SQLAlchemy) para sacar el código, y Limpiar para vaciar los dos paneles. Si no se encuentra ningún CREATE TABLE, el panel se vacía y Copiar avisa de que no hay nada que copiar.

Cómo se lee el DDL y qué contienen los modelos

Qué lee el analizador

Nombres de tabla, con o sin prefijo de esquema (app.accounts se emite como accounts), nombres de columna entre comillas invertidas, dobles o corchetes, y el tipo de cada columna. NOT NULL convierte el campo en obligatorio y una columna anulable queda opcional. Las claves primarias se toman de un PRIMARY KEY a nivel de columna y de un PRIMARY KEY (a, b) a nivel de tabla, incluidas las claves compuestas.

El autoincremento se deduce del DDL, no del nombre de la columna: se reconocen SERIAL, BIGSERIAL, AUTO_INCREMENT, GENERATED … AS IDENTITY y un valor por defecto nextval(…), mientras que un PRIMARY KEY normal se deja como clave corriente. DEFAULT CURRENT_TIMESTAMP y now() se traducen al valor «now» propio de cada destino. Las claves externas se leen tanto de REFERENCES a nivel de columna como de las cláusulas CONSTRAINT … FOREIGN KEY de tabla. Los comentarios de línea (-- y # de MySQL) y de bloque se eliminan antes de analizar.

Qué genera cada destino

Prisma: un modelo por tabla con @id, @@id([...]) cuando la clave abarca varias columnas, @default(autoincrement()) solo donde el DDL lo declara, @default(now()) para marcas de tiempo actuales, @db.Uuid para columnas UUID y @map / @@map para que los nombres generados sigan apuntando a los nombres SQL originales.

Drizzle ORM: declaraciones pgTable escritas para el dialecto de Postgres, con primaryKey({ columns: [...] }) en claves compuestas. TypeORM: @PrimaryGeneratedColumn solo en columnas autoincrementales y @PrimaryColumn en el resto de claves, de modo que los decoradores reflejen el esquema. SQLAlchemy: clases DeclarativeBase al estilo 2.0 con anotaciones Mapped[...], mapped_column() y ForeignKey('tabla.columna') para las dos formas de declarar claves externas; la lista de importaciones solo incluye lo que usan los modelos.

Revisa antes de dar por buenos los modelos

La correspondencia de tipos es deliberadamente gruesa. varchar, char, text y citext se convierten al tipo de cadena del destino, DECIMAL y NUMERIC a una columna decimal anotada como Decimal, JSON, JSONB y XML al tipo JSON genérico, y cualquier tipo desconocido cae en string. Compara una tabla representativa con el esquema real antes de generar migraciones a partir del resultado.

Todo lo que no es una columna se queda en la base de datos: CHECK, UNIQUE, índices, vistas, disparadores, secuencias, intercalaciones y cláusulas de almacenamiento no se convierten, y ningún destino recibe propiedades de relación ni de navegación: una clave externa sigue siendo una columna normal en todos salvo en SQLAlchemy, que añade ForeignKey. La salida de Drizzle usa el dialecto de Postgres sea cual sea el dialecto del DDL pegado.

Herramientas recientes: