ORM

Definición

ORM (siglas de Object-Relational Mapping, o mapeo objeto-relacional) es una capa de software que actúa como traductor entre dos mundos: el objetual de tu código (clases, instancias, propiedades) y el relacional de la base de datos (tablas, filas, columnas). En lugar de escribir SQL a mano, defines modelos en tu lenguaje y el ORM genera las consultas.

La promesa del ORM: trabajas con datos como si fueran objetos en memoria; el ORM se encarga de persistirlos en BD eficientemente. La realidad: ahorra mucho código repetitivo pero introduce abstracciones que pueden ocultar problemas de performance.

Cada lenguaje tiene sus ORM dominantes:

• Node.js/TypeScript: Prisma, Drizzle, TypeORM, Sequelize
• Python: SQLAlchemy, Django ORM
• Java: Hibernate, JPA
• Ruby: ActiveRecord (en Rails)
• PHP: Eloquent (en Laravel), Doctrine
• C#: Entity Framework

Cómo funciona

1. Defines un modelo en código que mapea a una tabla:

// Prisma schema
model Producto {
  id        Int      @id @default(autoincrement())
  nombre    String
  precio    Decimal
  stock     Int
  createdAt DateTime @default(now())
}

2. El ORM genera/usa la tabla correspondiente en la BD
3. Consultas con sintaxis del lenguaje, no SQL:

const productosCaros = await prisma.producto.findMany({
  where: { precio: { gt: 100 } },
  orderBy: { precio: 'desc' },
  take: 10
});

4. El ORM traduce a SQL, lo ejecuta y devuelve objetos del lenguaje hidratados.

Ejemplo práctico

Crear, leer, actualizar y borrar un producto usando Prisma:

import { PrismaClient } from '@prisma/client';
const prisma = new PrismaClient();

// CREATE
const nuevo = await prisma.producto.create({
  data: {
    nombre: 'Fresa carburo Ø10mm',
    precio: 23.50,
    stock: 47
  }
});

// READ
const todos = await prisma.producto.findMany({
  where: { stock: { gt: 0 } },
  orderBy: { nombre: 'asc' }
});

// UPDATE
await prisma.producto.update({
  where: { id: nuevo.id },
  data: { precio: 25.00 }
});

// DELETE
await prisma.producto.delete({
  where: { id: nuevo.id }
});

// JOIN con relaciones (sin escribir SQL JOIN)
const conResenas = await prisma.producto.findUnique({
  where: { id: nuevo.id },
  include: { resenas: true }
});

El ORM se encarga de:

• Mapear tipos del lenguaje a tipos de SQL (Number → INT, String → VARCHAR)
• Escapar valores para evitar SQL injection automáticamente
• Generar JOINs eficientes
• Devolver objetos tipados (con TypeScript: autocompletado total)

Ventajas reales

• Menos código repetitivo: te ahorras escribir SELECT/INSERT/UPDATE/DELETE básicos
• Type-safety: en lenguajes tipados (TypeScript, Java, C#), el ORM da autocompletado y catching de errores en tiempo de compilación
• Migraciones automáticas: la mayoría tienen sistema de versionado de schema
• Multi-BD: el mismo código puede correr sobre PostgreSQL, MySQL, SQLite con cambios mínimos
• Anti-SQL-injection: por defecto escapa todo (a menos que uses raw queries)

Desventajas / trade-offs

• Abstracción que oculta: a veces el ORM genera SQL ineficiente sin que lo notes
• Problema N+1: muy común — cargar una lista y luego, por cada item, hacer otra query. Mata performance. Hay que cuidarlo activamente (usar include/select adecuado).
• Curva de aprendizaje: dominar un ORM serio (Hibernate, SQLAlchemy) lleva tiempo
• Casos límite con SQL complejo: ventanas, CTEs, geoespaciales — a veces escribir SQL puro es más claro
• Magia oculta: cuando algo no funciona, debugear puede ser difícil porque hay capas de abstracción entre tu código y la BD

Tipos / variantes

• ORM "activo" (ActiveRecord pattern): el objeto tiene métodos para guardarse (producto.save()). Ej.: ActiveRecord en Rails, Eloquent en Laravel.
• ORM "data mapper": el objeto es solo datos; un repositorio aparte se encarga de persistir. Ej.: TypeORM, Doctrine. Más limpio en arquitecturas grandes.
• Query builders: NO son ORMs estrictos — solo te dan sintaxis fluida para generar SQL, sin mapear objetos. Ej.: Knex.js, Kysely. Compromiso entre productividad y control.
• "Lite" ORMs: minimalistas, sin migrar automáticamente, sin magia. Ej.: Drizzle (TypeScript). Cada vez más populares por evitar bloat.

Errores comunes

• N+1 queries por defecto: si cargas 100 productos y luego accedes a producto.resenas en un bucle, son 101 queries. Usa eager loading (include, select, populate).
• Lazy loading sin pensar: en algunos ORMs el acceso a una relación dispara una query sin que lo notes. Cuidado en serializaciones JSON.
• No mirar el SQL generado: cuando algo va lento, activa el log de SQL del ORM y mira qué está ejecutando realmente. Sorpresas habituales.
• Modelar como tablas en lugar de como dominio: el ORM no te exime de buen diseño. Las relaciones, índices y desnormalizaciones siguen siendo decisiones humanas.
• Confiar 100% en migraciones automáticas en producción: las migraciones generadas por ORM pueden borrar columnas o bloquear tablas grandes. Revisa siempre antes de ejecutar.
• Usar el ORM para todo cuando un SQL crudo sería más claro: para reportes complejos, ventanas, agregaciones avanzadas — escribe SQL. No pasa nada.

Cuándo usar ORM y cuándo no

Sí cuando:

• Tu app es CRUD-heavy con relaciones moderadas
• Quieres type-safety end-to-end (con TS o Java)
• Migraciones de schema serán frecuentes
• El equipo no es DBA experto y los queries básicos cubren el 90%

Considera SQL crudo (o query builder) cuando:

• La app es analítica con queries complejos
• Performance crítica con altísimo volumen
• Esquema fijo y muy estable
• Tu equipo es DBA y prefiere control total

Referencias

• Prisma docs — el ORM más popular en TypeScript moderno
• Martin Fowler — ORM Hate — discusión clásica sobre trade-offs
• Use The Index, Luke! — para entender qué SQL genera tu ORM y por qué a veces es lento