VoriTools

Gerador de modelos ORM a partir de SQL

Cole as tabelas e escolha o ORM. Copie o rascunho e adapte os tipos e o comportamento específico da aplicação antes de usar.

Funciona localmente no seu navegador
Ver categoria: SQL e bancos de dados (12)
Esta ferramenta processa todos os dados localmente no seu navegador.
DDL SQLCole instruções CREATE TABLE de MySQL, PostgreSQL, SQLite ou SQL Server. O analisador lê tabelas, colunas, chaves primárias e cláusulas REFERENCES diretas.
Modelos gerados

Como converter instruções CREATE TABLE em modelos ORM

Cole instruções CREATE TABLE, escolha Prisma, Drizzle, TypeORM ou SQLAlchemy e clique em Gerar modelos. Todas as tabelas do texto são lidas — colunas, tipos, NOT NULL, chaves primárias, valores padrão e chaves estrangeiras — e o resultado traz um bloco de modelo por tabela, pronto para copiar ou baixar.

Tudo acontece na página: a geração não disparou nenhuma requisição de rede nos testes, então o esquema não sai do navegador e a ferramenta continua funcionando quando a conexão cai.

  1. Cole o DDL no painel DDL SQL ou clique em Carregar exemplo para começar com duas tabelas pequenas.
  2. Escolha o destino em Gerar para: Prisma, Drizzle ORM, TypeORM ou SQLAlchemy.
  3. Clique em Gerar modelos. A linha de status informa quantos modelos de tabela foram criados e avisa quando alguma definição do DDL colado não pôde ser lida.
  4. Troque o destino quando quiser: o painel é regerado, então o código sempre corresponde ao ORM indicado ao lado dele.
  5. Use Copiar ou Baixar (models.ts, ou models.py para SQLAlchemy) para levar o código e Limpar para esvaziar os dois painéis. Se nenhum CREATE TABLE for encontrado, o painel fica vazio e Copiar avisa que não há nada para copiar.

Como o DDL é lido e o que os modelos contêm

O que o analisador lê

Nomes de tabela, com ou sem prefixo de esquema (app.accounts sai como accounts), nomes de coluna entre crases, aspas duplas ou colchetes, e o tipo de cada coluna. NOT NULL torna o campo obrigatório e uma coluna anulável fica opcional. As chaves primárias vêm de um PRIMARY KEY no nível da coluna e de um PRIMARY KEY (a, b) no nível da tabela, incluindo chaves compostas.

O autoincremento vem do DDL, não do nome da coluna: SERIAL, BIGSERIAL, AUTO_INCREMENT, GENERATED … AS IDENTITY e um padrão nextval(…) são reconhecidos, enquanto um PRIMARY KEY comum continua sendo apenas uma chave. DEFAULT CURRENT_TIMESTAMP e now() viram o padrão “now” de cada destino. As chaves estrangeiras são lidas tanto de REFERENCES no nível da coluna quanto de cláusulas CONSTRAINT … FOREIGN KEY da tabela. Comentários de linha (-- e # do MySQL) e de bloco são removidos antes da análise.

O que cada destino gera

Prisma: um modelo por tabela com @id, @@id([...]) quando a chave ocupa várias colunas, @default(autoincrement()) apenas onde o DDL declara, @default(now()) para timestamps atuais, @db.Uuid para colunas UUID e @map / @@map para os nomes gerados continuarem apontando para os nomes SQL originais.

Drizzle ORM: declarações pgTable escritas para o dialeto do Postgres, com primaryKey({ columns: [...] }) em chaves compostas. TypeORM: @PrimaryGeneratedColumn apenas em colunas autoincrementais e @PrimaryColumn nas demais chaves, para os decoradores refletirem o esquema. SQLAlchemy: classes DeclarativeBase no estilo 2.0 com anotações Mapped[...], mapped_column() e ForeignKey('tabela.coluna') nas duas formas de chave estrangeira; a lista de imports contém só o que os modelos usam.

Confira antes de usar o resultado

O mapeamento de tipos é grosseiro de propósito. varchar, char, text e citext viram o tipo de texto do destino, DECIMAL e NUMERIC viram coluna decimal anotada como Decimal, JSON, JSONB e XML usam o tipo JSON genérico, e qualquer tipo desconhecido cai em string. Compare uma tabela representativa com o esquema real antes de gerar migrações a partir da saída.

O que não é coluna continua no banco: CHECK, UNIQUE, índices, views, triggers, sequences, collations e cláusulas de armazenamento não são convertidos, e nenhum destino recebe propriedades de relação ou navegação — a chave estrangeira continua sendo uma coluna simples em todos, menos no SQLAlchemy, que adiciona ForeignKey. A saída do Drizzle usa o dialeto do Postgres independentemente do dialeto do DDL colado.

Ferramentas recentes: