ORM abstrai SQL, aumenta produtividade mas esconde performance. Query Builder é SQL-like, controle total. Entenda trade-offs.

CrazyStack8 de fevereiro de 202610 min de leituracompartilharX LinkedIn WhatsApp

Conceitos Principais

Object-Relational Mapping. Entities → classes. Queries → métodos. Magic: migrations, relations. Exemplos: Prisma, TypeORM, Sequelize.

Programatic SQL. Knex, Kysely. Type-safe. Sem abstração excessiva. Mais controle.

ORMs lazy-load relations. Loop de N queries. Solução: eager loading. Query builders não têm problema.

ORMs: auto-generate. Query builders: manual. Trade-off: magic vs controle.

Passo a Passo

ORM Example (Prisma): const users = await prisma.user.findMany({ where: { active: true }, include: { posts: true }}). Type-safe, auto-complete.
Query Builder (Knex): const users = await knex("users").where({ active: true }).join("posts", "users.id", "posts.user_id").select("*"). More verbose, SQL-like.
Performance Test: ORM N+1: 1 + N queries. Eager: 2 queries (JOIN). Query builder: 1 query sempre. Measure com EXPLAIN.
Complex Query: ORM: queryRaw ou query builder. Query Builder: natural. Subqueries, CTEs mais fáceis.
Decisão: ORM: startups, CRUD-heavy, time-to-market. Query Builder: performance crítica, complex queries, control.

• ORM para CRUD simples

• Query builder para complex queries

• Hybrid: ORM + raw queries

• Always measure performance

• Eager load relations em ORM

• Index como se SQL direto

• ORM para tudo (performance issues)

• Não identificar N+1

• Raw SQL em strings (injection risk)

• Ignorar EXPLAIN

• Não testar performance