Lección 13 de 17 · Lectura y práctica
Planificar y Diseñar el Schema del Proyecto
Concepto clavePlanificar y diseñar el schema de Prisma es como crear los planos de un edificio antes de construirlo. En producción, un mal diseño puede llevar a problemas de rendimiento, migraciones costosas y dificultades para.
Del concepto a la práctica
Taller de esta lección
El diseño integrador debe comenzar por casos de uso y no por una lista arbitraria de tablas. Para reservar salas necesitas consultar disponibilidad por sala y rango temporal, crear una reserva vinculada a usuario y sala y conservar su estado. Esas operaciones determinan claves e índices.
Ejemplo resuelto
Entidades: User, Room, Reservation. Una reserva tiene userId, roomId, startsAt, endsAt y status. El índice compuesto [roomId, startsAt] ayuda a localizar el calendario de una sala.
Disponibilidad es ausencia de solapamiento entre intervalos activos de una sala: existente.startsAt < nueva.endsAt Y existente.endsAt > nueva.startsAt. Usa intervalos [inicio,fin), de modo que10–11 y11–12 no se solapan. Una lectura de disponibilidad seguida de create puede competir con otra petición; protege el invariante en DB/transacción, no solo en la validación previa. En PostgreSQL considera exclusión GiST por sala/rango con migración SQL revisada, o serialización con reintentos acotados y misma política de estados.
Pruébalo
Escribe tres consultas principales del proyecto.
Extrae las entidades y relaciones necesarias.
Marca reglas que requieren validación de aplicación.
Justifica cada índice con una consulta concreta.
Comprueba tu resultado
El diagrama debe mostrar una reserva conectada a exactamente un usuario y una sala, y cada sala puede tener muchas reservas.
Error frecuente: crear un modelo Availability duplicando datos calculables sin necesidad. Corrígelo calculando disponibilidad desde reservas confirmadas, salvo que exista un requisito explícito de calendario materializado.
Ejercicio: con dos salas y tres reservas, verifica que cada reserva tiene ambas claves foráneas y que el índice propuesto incluye roomId.

Mapa de prácticaUna clave conecta cada pedido con su cliente. INNER JOIN devuelve las coincidencias y puede producir varias filas por cliente. LEFT JOIN conserva también los clientes sin pedido y representa los campos ausentes con NULL.
Ver la infografía en tamaño completo ↗Concepto clave
Planificar y diseñar el schema de Prisma es como crear los planos de un edificio antes de construirlo. En producción, un mal diseño puede llevar a problemas de rendimiento, migraciones costosas y dificultades para escalar. El schema define la estructura de tu base de datos, las relaciones entre entidades y las reglas de validación.
Imagina que estás diseñando una plataforma de e-commerce. Sin un buen schema, podrías terminar con tablas desorganizadas, relaciones incorrectas o falta de índices, lo que ralentizaría las consultas cuando tengas miles de usuarios. Un diseño sólido anticipa el crecimiento, optimiza las consultas frecuentes y asegura la integridad de los datos desde el inicio.
Cómo funciona en la práctica
El proceso de diseño sigue estos pasos: primero, identifica las entidades principales (como Usuario, Producto, Orden). Luego, define sus atributos y tipos de datos apropiados. Después, establece las relaciones (uno a uno, uno a muchos, muchos a muchos). Finalmente, agrega índices, valores por defecto y validaciones.
Por ejemplo, para un sistema de blog con usuarios y posts:
- Entidad Usuario: id, email, nombre, fechaCreacion
- Entidad Post: id, titulo, contenido, autorId, fechaPublicacion
- Relación: Un usuario puede tener muchos posts (uno a muchos)
- Índices: En email del usuario y autorId del post para búsquedas rápidas
Código en acción
Schema inicial básico:
model Usuario {
id Int @id @default(autoincrement())
email String @unique
nombre String?
posts Post[]
createdAt DateTime @default(now())
}
model Post {
id Int @id @default(autoincrement())
titulo String
contenido String
autor Usuario @relation(fields: [autorId], references: [id])
autorId Int
publicado Boolean @default(false)
createdAt DateTime @default(now())
}
@@index([autorId])
@@index([createdAt])
Schema mejorado para producción:
model Usuario {
id Int @id @default(autoincrement())
email String @unique @db.VarChar(255)
nombre String? @db.VarChar(100)
posts Post[]
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
@@map("usuarios")
}
model Post {
id Int @id @default(autoincrement())
titulo String @db.VarChar(200)
contenido String @db.Text
autor Usuario @relation(fields: [autorId], references: [id], onDelete: Cascade)
autorId Int
publicado Boolean @default(false)
slug String @unique @db.VarChar(255)
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
@@map("posts")
@@index([autorId])
@@index([createdAt])
@@index([slug])
}
Errores comunes
- No definir longitudes de campos: Usar String sin @db.VarChar puede llevar a ineficiencias en bases de datos como MySQL. Especifica longitudes máximas realistas.
- Olvidar relaciones bidireccionales: Si un Usuario tiene muchos Posts, asegúrate de que Post tenga el campo autorId y la relación @relation definida correctamente.
- Falta de índices en campos de búsqueda frecuente: Campos como email, fechas o claves foráneas deben estar indexados para optimizar consultas.
- No planificar eliminaciones en cascada: Define onDelete e onUpdate en relaciones para mantener la integridad referencial.
- Ignorar el mapeo de nombres de tabla: Usa @@map para nombres de tabla en plural o que sigan convenciones de tu equipo.
Checklist de dominio
- ¿Identificaste todas las entidades principales y sus atributos con tipos de datos apropiados?
- ¿Definiste correctamente las relaciones (uno a uno, uno a muchos, muchos a muchos) entre entidades?
- ¿Agregaste índices en campos usados frecuentemente en WHERE, ORDER BY o JOIN?
- ¿Especificaste longitudes de campos (ej. @db.VarChar) y valores por defecto donde sea necesario?
- ¿Incluiste campos de auditoría como createdAt y updatedAt?
- ¿Usaste @@map para nombres de tabla consistentes y siguiendo convenciones?
- ¿Probaste el schema generando una migración y verificando que no haya errores?
Diseña un Schema para un Sistema de Reservas de Hotel
En este ejercicio, crearás un schema de Prisma para un sistema de reservas de hotel en producción. Sigue estos pasos:
- Identifica las entidades principales: Hotel, Habitacion, Cliente, Reserva.
- Define los atributos de cada entidad con tipos de datos apropiados (ej. fechas como DateTime, precios como Decimal).
- Establece las relaciones: Un hotel tiene muchas habitaciones, una habitación pertenece a un hotel, un cliente puede tener muchas reservas, una reserva está asociada a una habitación y un cliente.
- Agrega índices en campos críticos como fechas de reserva, email del cliente, o número de habitación.
- Incluye validaciones como @unique para emails y valores por defecto para campos como estado de reserva.
- Escribe el código en un archivo schema.prisma y genera una migración para probarlo.
Pistas
- Considera usar tipos Decimal para precios para evitar problemas de precisión con Float.
- Agrega un campo 'estado' en Reserva con valores como 'pendiente', 'confirmada', 'cancelada'.
- Usa onDelete e onUpdate en relaciones para manejar eliminaciones de clientes o hoteles.
Evalua tu comprension
Completa el quiz interactivo de arriba para ganar XP.
Sigue con Prisma ORM Profesional: Schemas, Migraciones y Queries Optimizadas para Producción
Esta lección forma parte de un curso de Cursalo. Revisa su programa y elige entre la compra individual o el acceso a toda la escuela.
Si ya tenías acceso a este curso, entra con tu cuenta: tus derechos y tu progreso se conservan. No necesitas comprarlo de nuevo.