¿Poner toda la lógica en el backend o usar el ORM como cajón de sastre?

FilmBuff

Muy buenas, hacknianos. Llevo unos meses con un proyecto en Node + PostgreSQL usando Prisma como ORM. La cuestión es que vengo de un entorno donde la lógica de negocio se escribía en procedimientos almacenados y ahora me debato entre dos enfoques:

1. Lógica gruesa en el ORM: Validaciones, cálculos y reglas directamente en los servicios de Node, usando Prisma para todo. Rápido de escribir y testear, pero siento que mezclo capas y la BD queda como un simple almacén.

2. Lógica en la base de datos: Triggers, constraints complejas, vistas materializadas y funciones. Más robusto y consistente, pero el equipo de frontend dice que es un infierno para debuggear.

¿Cuál es la práctica recomendada hoy en día para proyectos medianos? ¿Alguien ha migrado de un enfoque a otro y ha notado mejoras reales? Cualquier ejemplo de código o experiencia se agradece.

Ballet

Depende mucho del tamaño del equipo y de la criticidad de los datos. En mi curro tenemos un sistema financiero y la lógica de cálculo de intereses está en funciones PL/pgSQL. ¿Por qué? Porque si un bug corrompe los datos, no quieres depender de que todos los servicios Node hayan actualizado su versión. La BD es la última línea de defensa.

Dicho esto, para CRUDs normales, tener triggers por todos lados es un dolor de cabeza para las migraciones. Yo uso un híbrido: constraints y triggers solo para integridad referencial y auditoría, y toda la lógica de negocio en la capa de servicios con tests unitarios.

Tea

Totalmente en desacuerdo con meter lógica en triggers. He visto proyectos donde un simple INSERT desencadena 5 triggers que a su vez llaman a funciones que actualizan otras tablas. Debuggear eso es un infierno. Además, el equipo de frontend tiene razón: si la lógica está en la BD, no pueden mockearla fácilmente para pruebas de integración.

Mi recomendación: mantén la BD tonta. Usa Prisma o TypeORM para validaciones básicas y deja que los servicios manejen las reglas. Si necesitas consistencia fuerte, usa transacciones y aislamiento, pero no triggers.

FilmBuff

Gracias por las respuestas. El primer comentario me ha hecho pensar en la parte de auditoría, que es un requisito legal en mi caso. Nunca había considerado usar triggers solo para eso. ¿Alguien tiene un ejemplo de trigger de auditoría que no sea un dolor de cabeza mantenerlo?

Por otro lado, el segundo tiene razón en lo del frontend. Pero, ¿no es cierto que con un ORM como Prisma acabas duplicando validaciones? Porque las constraints de la BD también validan, y si no coinciden, tienes errores inconsistentes.

Urban

Sobre la duplicación de validaciones: sí, es un mal necesario. La práctica común es tener validaciones en el ORM para dar mensajes de error amigables, y constraints en la BD como red de seguridad. No es duplicar lógica, es defensa en profundidad. Lo importante es que la fuente de verdad sea una sola: por ejemplo, define las reglas en un schema de Zod y genera las constraints a partir de ahí si usas herramientas como pg-generate-constraints.

Para auditoría, un trigger sencillo que copie el registro antiguo a una tabla audit_log con jsonb es suficiente y no interfiere con la lógica de negocio. Te dejo un ejemplo:

CREATE OR REPLACE FUNCTION audit_trigger() RETURNS trigger AS $
BEGIN
  INSERT INTO audit_log(table_name, operation, old_data, new_data)
  VALUES (TG_TABLE_NAME, TG_OP, row_to_json(OLD), row_to_json(NEW));
  RETURN NEW;
END;
$ LANGUAGE plpgsql;

Anime

Yo he migrado de lógica en BD a lógica en servicios y la mejora fue brutal en velocidad de desarrollo. Antes, cada cambio requería una migración compleja y coordinar con DBAs. Ahora, con Prisma, hago prisma migrate dev y listo. Eso sí, perdimos algo de rendimiento en consultas complejas, pero lo compensamos con índices y caché.

Mi consejo: si tu equipo no tiene un DBA dedicado, no metas lógica en la BD. Esa responsabilidad recae en los desarrolladores y no siempre tienen el conocimiento profundo de PostgreSQL.

FilmBuff

Me queda mucho más claro. La idea de defensa en profundidad y usar triggers solo para auditoría me convence. Creo que voy a reescribir mis validaciones con Zod y generar las constraints desde ahí, como sugirió el ejemplo. Y dejar la BD solo con integridad referencial y auditoría.

Gracias a todos, este hilo me ha ahorrado semanas de prueba y error.

Cocktails

El enfoque de Zod como fuente única para validaciones y constraints es sólido, pero cuidado: no todas las reglas de negocio son expresables en un schema de Zod. Las que dependen de estado (ej. 'un pedido no puede modificarse si ya está enviado') requieren lógica en el servicio o en triggers. Si intentas forzarlas en Zod acabarás con validaciones incompletas o duplicadas de forma caótica.

Además, generar constraints desde Zod solo cubre checks simples (tipos, rangos, regex). Las reglas que involucran múltiples tablas o agregados (ej. stock disponible) no las puedes poner en un CHECK, necesitas transacciones y bloqueos en el servicio. Ahí es donde el ORM como cajón de sastre se queda corto y acabas metiendo lógica en la BD de todas formas, pero sin control.

Mi recomendación: Zod para validación de entrada y constraints básicas, triggers solo para auditoría, y toda la lógica de negocio con estado en la capa de servicio. Si el rendimiento duele, usa SELECT ... FOR UPDATE o caché distribuida, pero no sacrifiques la mantenibilidad.