Pregunta abierta para variar de las peticiones de ayuda con ejercicios: ¿alguna vez migrasteis un proyecto que usaba mucho PL/SQL (lógica de negocio metida en procedimientos y triggers dentro de la base de datos) hacia otro enfoque, moviendo esa lógica a la capa de aplicación?

Me interesa sobre todo la experiencia real: ¿mereció la pena, o fue un dolor de cabeza que os hizo echar de menos PL/SQL a mitad de proyecto? ¿Qué se ganó y qué se perdió al mover la lógica fuera de la base de datos?

Y para los que seguís trabajando fuerte con PL/SQL: ¿qué es lo que os hace preferirlo frente a tener esa lógica en el backend?

Jota CT

Mi experiencia, resumida: PL/SQL sigue siendo difícil de superar para lógica pesada de datos que ya vive cerca de la base de datos (agregaciones grandes, procesos batch nocturnos, integridad que de verdad tiene que garantizarse sí o sí). Ahí moverlo a la capa de aplicación normalmente significa mover también los datos por la red innecesariamente, y eso sale caro en rendimiento.

Donde sí he visto que compensa migrar fuera de PL/SQL es en reglas de negocio que cambian con frecuencia y que se benefician de tests automatizados, control de versiones con historial legible, y despliegues independientes de la base de datos. Un trigger con lógica de negocio compleja es notoriamente difícil de testear de forma aislada y de revisar en un diff de pull request, comparado con una función en cualquier lenguaje de aplicación moderno.

Mi regla práctica: si la lógica necesita moverse por la red para razonar sobre los datos, que se quede en la base de datos. Si la lógica es de negocio y cambia a menudo, que salga de la base de datos aunque cueste un poco más de latencia por las idas y venidas.

David Carrero