O que é um ORM? Como os apps conversam com bancos de dados, explicado

Um ORM (object-relational mapper) é uma biblioteca de código que fica entre um app e um banco de dados relacional. Em vez de escrever consultas ao banco em SQL, os desenvolvedores trabalham com os dados como objetos comuns na sua linguagem de programação — db.booking.create(...) ou Booking.find(...) — e o ORM traduz isso para SQL, executa a consulta e transforma os resultados de volta em objetos. Exemplos populares são Prisma e Drizzle para TypeScript, SQLAlchemy para Python e Entity Framework Core para C#.

Por que os ORMs importam quando você cria com IA

Quando um criador de apps com IA adiciona um banco de dados ao seu app, geralmente também adiciona um ORM para conversar com ele. Você não precisará escrever código de ORM, mas ajuda saber que ele está ali:

• Seu modelo de dados vive no código. O arquivo de esquema do ORM costuma ser a descrição mais clara dos dados do seu app: quais tabelas existem, quais campos cada uma tem e como se conectam. Lê-lo é uma forma rápida de conferir se a IA entendeu o seu app.
• Mudanças no banco passam por migrações. Quando você pede "adicione um número de telefone aos clientes", a IA atualiza o modelo e cria uma migração. Saber disso ajuda a entender por que uma mudança pode precisar ser aplicada antes de funcionar no ar.
• Segurança por padrão. Os ORMs montam as consultas de um jeito que protege contra SQL injection, uma das falhas de segurança mais comuns em apps que montam consultas à mão.
• Armadilhas de lentidão. Os ORMs facilitam executar, sem querer, centenas de consultas pequenas quando uma só bastaria. É uma causa comum de páginas lentas em apps criados com IA.

Uma analogia do dia a dia

Imagine um viajante britânico e um lojista japonês que não falam a mesma língua e conversam por meio de um intérprete.

O viajante (seu app) diz: "Gostaria dos três chás mais baratos que você tem." O intérprete (o ORM) traduz isso para um japonês preciso (SQL), entrega ao lojista (o banco de dados) e traduz a resposta de volta para o inglês.

O viajante nunca aprende japonês, e para a maioria das conversas isso não é um problema. Mas em uma negociação complicada, pode ajudar falar diretamente — por isso a maioria dos ORMs permite escrever SQL puro quando necessário.

Como um ORM funciona

Bancos como o Postgres guardam os dados em tabelas de linhas e colunas, e são consultados com SQL. As linguagens de programação trabalham com objetos: uma reserva com uma date, um customer e um status. O ORM faz a ponte entre os dois:

Essas quatro operações são as ações CRUD sobre as quais quase todo app é construído.

Um exemplo prático: reservas com Prisma

Aqui está um esquema Prisma simplificado para um app de reservas de salão. Ele descreve duas tabelas e como elas se ligam:

model Customer {
  id       Int       @id @default(autoincrement())
  name     String
  email    String    @unique
  bookings Booking[]
}

model Booking {
  id         Int      @id @default(autoincrement())
  startsAt   DateTime
  service    String
  customer   Customer @relation(fields: [customerId], references: [id])
  customerId Int
}

Em palavras simples: um cliente tem um nome, um e-mail único e muitas reservas; cada reserva tem um horário de início, um serviço e pertence a um único cliente.

Agora o app precisa de "as próximas reservas da Lena, da mais cedo para a mais tarde":

const bookings = await db.booking.findMany({
  where: {
    customer: { email: "lena@example.com" },
    startsAt: { gte: new Date() },
  },
  orderBy: { startsAt: "asc" },
});

O ORM transforma isso em SQL, mais ou menos assim, executa e devolve uma lista de objetos de reserva:

SELECT b.* FROM "Booking" b
JOIN "Customer" c ON c.id = b."customerId"
WHERE c.email = $1 AND b."startsAt" >= $2
ORDER BY b."startsAt" ASC;

O $1 e o $2 são marcadores: o e-mail e a data são enviados separadamente do texto da consulta, e é isso que impede o SQL injection.

Migrações

Se você pedir em seguida "deixe os clientes adicionarem um número de telefone", a IA acrescenta phone String? ao modelo Customer (o ? significa opcional) e gera uma migração — um pequeno script SQL como ALTER TABLE "Customer" ADD COLUMN "phone" TEXT;. As migrações são salvas em ordem, para que qualquer cópia do banco possa ser levada à mesma estrutura, e o histórico de mudanças fica preservado.

ORMs comuns por linguagem

Os ORMs variam em quanto escondem o SQL. O Prisma usa uma linguagem de esquema própria e um estilo de consulta próprio; o Drizzle propositalmente se mantém próximo da forma do SQL, mantendo tudo tipado. Ferramentas mais leves chamadas query builders, como Knex ou Kysely para TypeScript, ajudam a montar SQL no código sem mapear as linhas para objetos completos.

Termos-chave

Equívocos comuns

• "Um ORM é um banco de dados." Não é. É um tradutor. Você ainda precisa de um banco como o Postgres.
• "Com um ORM você não precisa entender os seus dados." Tabelas mal planejadas dão tanto problema através de um ORM quanto sem ele. Um bom modelo de dados importa mais do que a ferramenta.
• "ORMs são sempre lentos." As consultas do dia a dia são rápidas. A lentidão geralmente vem de padrões como consultas N+1 ou falta de índices, que podem ser corrigidos.
• "ORM significa que nunca há risco de SQL injection." Os métodos padrão do ORM são seguros, mas SQL puro escrito com dados do usuário colados diretamente continua sendo perigoso.
• "Editar o arquivo de esquema altera o banco em produção." Só depois que uma migração é criada e aplicada àquele banco.

O que perguntar ao seu criador com IA

• "Mostre o esquema do banco de dados e explique cada tabela e relacionamento em português simples."
• "Qual ORM este projeto usa, e onde estão as migrações?"
• "Antes de mudar qualquer tabela, diga se os dados existentes serão afetados, e nunca remova uma coluna que tenha dados sem me perguntar."
• "Verifique as páginas mais lentas em busca de consultas N+1 e adicione índices onde as listas são filtradas ou ordenadas."
• "Garanta que toda consulta que usa dados do usuário passe pelo ORM ou use parâmetros — nada de SQL montado por concatenação de texto."

ORMs no Mythex

Quando o seu app precisa salvar dados, o Mythex adiciona um banco Postgres dedicado ao projeto — peça no chat ou use o comando /database — e injeta os detalhes de conexão no workspace e no app publicado (Database). O agente então escreve o código que lê e salva os seus dados. Se você tiver uma preferência — "use Prisma", "use SQLAlchemy" ou "SQL puro, sem ORM" — diga isso no chat. Peça para ele explicar o esquema sempre que quiser conferir a estrutura; você pode ler os arquivos no editor de código. Para a visão geral, veja o que é um banco de dados e SQL vs NoSQL.

Perguntas