A diferencia del código de lenguaje de programación real, ellos:
- no portátil (cada base de datos tiene su propia versión de PL/SQL. A veces, diferentes versiones del mismo base de datos son incompatibles - ¡Lo he visto!)
- no es fácil de probar:necesita un real (dev) instancia de la base de datos para probarlos y, por lo tanto, la prueba unitaria de su código como parte de una compilación es prácticamente imposible
- no se pueden actualizar/liberar fácilmente:debe eliminarlos/crearlos, es decir, modificar la base de datos de producción para liberarlos
- no tiene soporte de biblioteca (¿por qué escribir código cuando alguien más lo tiene)
- no son fácilmente integrables con otras tecnologías (intente llamar a un servicio web desde ellas)
- utilizan un lenguaje tan primitivo como Fortran y, por lo tanto, son poco elegantes y laboriosos para realizar una codificación útil, por lo que es difícil expresar la lógica comercial, aunque normalmente ese es su propósito principal
- no ofrecen depuración/rastreo/registro de mensajes, etc. (algunos dbs pueden admitir esto, aunque no lo he visto)
- carecen de un IDE decente para ayudar con la sintaxis y la vinculación a otros procedimientos existentes (por ejemplo, como lo hace Eclipse para Java)
- las personas expertas en codificarlas son menos frecuentes y más caras que los programadores de aplicaciones
- su "alto rendimiento" es un mito, ya que se ejecutan en el servidor de base de datos y suelen aumentar la carga del servidor de base de datos, por lo que su uso generalmente reducirá su rendimiento máximo de transacciones
- incapacidad para compartir constantes de manera eficiente (normalmente se resuelve creando una tabla y buscándola desde dentro de su procedimiento, muy ineficiente)
- etc.
Si tiene una acción muy específica de la base de datos (p. ej., una acción en una transacción para mantener la integridad de la base de datos) o mantiene sus procedimientos muy atómicos y simples, tal vez podría considerarlos.
Se recomienda precaución al especificar "alto rendimiento" por adelantado. A menudo conduce a malas decisiones a expensas de un buen diseño y te afectará mucho antes de lo que piensas.
Utilice los procedimientos almacenados bajo su propio riesgo (de alguien que ha estado allí y nunca quiere volver). Mi recomendación es evitarlos como la peste.
