¿Deberíamos evitar completamente los procedimientos almacenados en 2024?

Pottery

Hola a todos, llevo unos meses trabajando en un proyecto legacy que usa muchísimos procedimientos almacenados (stored procedures) para lógica de negocio. Estoy considerando migrar a lógica en la capa de aplicación con un ORM moderno. Mi duda es: ¿realmente vale la pena o hay casos donde los procedimientos almacenados siguen siendo una buena práctica? ¿Qué opinan sobre rendimiento, mantenibilidad y seguridad?

SpaceFan

Yo creo que depende del contexto. Si trabajas con bases de datos distribuidas o necesitas reducir el tráfico entre app y BD, los stored procedures pueden ser más eficientes. Pero en equipos grandes, la lógica en la app es más testeable y versionable. Mi recomendación: evalúa si realmente el cuello de botella está en la red o en los cálculos.

Blockchain

Totalmente de acuerdo con que los stored procedures son difíciles de mantener y depurar. Además, en entornos cloud (como PostgreSQL en RDS) ya no hay ventaja significativa de rendimiento. Yo migraría a una capa de servicio con TypeORM o Prisma y usaría migraciones. Pero ojo: no sacrifiques integridad referencial ni validaciones complejas que la BD hace bien.

Fashion

Tengo experiencia en fintech y ahí seguimos usando stored procedures para transacciones críticas. La razón: consistencia y atomicidad. Con un ORM puedes tener race conditions si no manejas bien las transacciones. Eso sí, documentamos cada SP y usamos control de versiones con Git para scripts SQL. No es blanco o negro.

Pottery

Gracias por las respuestas. Me preocupa especialmente el tema de testing y versionado. ¿Alguno ha usado Flyway o Liquibase para versionar stored procedures? ¿O recomiendan mejor migrar todo a código de aplicación con transacciones explícitas?

Fitness

Yo he usado Flyway para versionar SP y funciona, pero es engorroso. Si decides mantenerlos, al menos encapsula la lógica en funciones puras y evita SPs monolíticos. Mi voto es migrar gradualmente: primero mover lógica simple a la app y dejar lo crítico en BD hasta que tengas confianza.

TechReview

Un punto importante: los SPs pueden ser un vector de ataque si no sanitizas entradas. En cambio, un ORM bien configurado te da protección contra inyección SQL por defecto. Si tu equipo es pequeño y ágil, yo me iría por código en la app. Para equipos grandes con DBA dedicados, los SPs aún tienen sentido.