Express con Prisma y PostgreSQL

La persistencia relacional exige definir entidades, relaciones y reglas de integridad antes de escribir consultas. Prisma puede encapsular el acceso, pero no decide por ti si una inscripción duplicada es válida ni qué hacer cuando falta un curso.

Ejemplo resuelto

Usa tres registros: usuario u1, curso c1 y una inscripción i1 que relaciona ambos. La operación POST /enrollments debe verificar que u1 y c1 existan y que no haya otra relación igual. Una restricción única sobre usuario y curso refuerza la regla en la base de datos; el servicio traduce la violación a un conflicto HTTP.

Modelo conceptual: User(id), Course(id) y Enrollment(id, userId, courseId) con relaciones y @@unique([userId, courseId]) en Enrollment. Vincula userId a la identidad autenticada; no permitas que el body elija otra persona. Para Prisma 7 sigue su configuración y cliente generado actuales, incluidos salida explícita y adaptador PostgreSQL; un ejemplo de Prisma 6 con importación desde @prisma/client no es una receta universal para la versión nueva. La restricción evita duplicados incluso con peticiones simultáneas.

Pruébalo

1. Dibuja entidades y claves antes del modelo.

2. Define relaciones y restricciones únicas.

3. Encapsula la consulta en un servicio o repositorio.

4. Prueba creación, duplicado y referencia inexistente.

Error frecuente: llamar al cliente de datos desde cada ruta. Corrígelo concentrando consultas y decisiones de dominio en una capa reutilizable.

Comprueba tu resultado

Con u1, c1 e i1, una segunda inscripción idéntica no debe generar i2; debe producir conflicto. Un courseId c9 inexistente debe producir 404 y dejar intacta la tabla de inscripciones.