Los procedimientos almacenados han estado cayendo en desgracia durante varios años. El enfoque preferido en estos días para acceder a una base de datos relacional es a través de un asignador O/R como NHibernate o Entity Framework.
Los procedimientos almacenados requieren mucho más trabajo para desarrollar y mantener. Para cada tabla, debe escribir procedimientos almacenados individuales para crear, recuperar, actualizar y eliminar una fila, además de un procedimiento almacenado por separado para cada consulta diferente que desee realizar. Además de eso, debe escribir clases y/o métodos en su código para llamar a cada procedimiento almacenado. Compare eso con un asignador O/R: todo lo que necesita escribir son sus definiciones de clase, su tabla de base de datos y un archivo de mapeo.De hecho, los ORM modernos usan un enfoque basado en convenciones que elimina la necesidad de una definición de mapeo separada.
Los procedimientos almacenados promueven malas prácticas de desarrollo, en particular requieren que viole DRY (No repita), ya que debe escribir la lista de campos en la tabla de la base de datos media docena o más en menos. Esto es un dolor masivo si necesita agregar una sola columna a su tabla de base de datos. No es posible pasar un objeto como parámetro a un procedimiento almacenado, solo tipos simples (cadena, número entero, fecha/hora, etc.) lo que hace casi imposible evitar grandes listas de parámetros (una docena o más).
Los procedimientos almacenados promueven malas prácticas de gestión de configuración. Esto surge del argumento de que los DBA deberían poder modificarlos independientemente del código en sí. Hacer esto da como resultado una versión de su código entrando en producción que nunca ha sido probada de integración, no corresponde a una única revisión específica en control de fuente, y de hecho ni siquiera corresponde a revisión en control de fuente en absoluto. Básicamente, si no tienes un registro auditable, de principio a fin, de exactamente qué revisión de tu código está en producción, vas a tener problemas.
Los procedimientos almacenados tienen que implementarse por separado del cuerpo principal de su código. A menos que tenga un proceso totalmente automatizado para actualizarlos, existe un riesgo dramáticamente mayor de que puedan desincronizarse con su base de código principal en uno o más entornos, introduciendo errores. Esto es especialmente problemático si necesita usar la herramienta de bisección del control de origen para rastrear la revisión que introdujo un error.
Los procedimientos almacenados son inflexibles. Si desea consultar sus datos de varias formas diferentes (diferentes órdenes de clasificación, carga lenta o anhelada, paginación, etc.) tendrá que escribir una multitud de procedimientos almacenados por separado para todos los casos de uso diferentes, mientras que los ORM le dan una flexibilidad, potente lenguaje de consulta (por ejemplo, Linq a NHibernate).
Los procedimientos almacenados requieren reinventar las ruedas. Si necesita simultaneidad optimista, o un patrón de Unidad de trabajo, o carga lenta, o un Mapa de identidad, o manejo de colecciones padre/hijo, o almacenamiento en memoria caché, o asignaciones de jerarquía de clases, o prácticamente cualquiera de los otros patrones de diseño sobre los que lee en el libro de Martin Fowler, Patrones de la arquitectura de aplicaciones empresariales, necesita reconstruir esta funcionalidad desde cero, mientras que un asignador O/R le ofrece todo esto, y más, nada más sacarlo de la caja. Muy a menudo, terminarás reinventando estas ruedas usando el código de copiar y pegar, lo que de nuevo es una mala práctica.
Los procedimientos almacenados son difíciles de probar en una unidad. Con un ORM, puede simular el código de su base de datos para poder probar su lógica comercial rápidamente. Con los procedimientos almacenados, debe reconstruir una base de datos de prueba completa desde cero.
Los procedimientos almacenados no ofrecen ninguna ventaja de rendimiento en absoluto. Las (pequeñas) ganancias que obtiene al pasar solo el nombre del sproc por el cable en lugar de una cadena SQL se compensan fácilmente por el hecho de que es muy probable que termine llamando al mismo procedimiento dos o tres veces con el mismo parámetros en la misma solicitud, mientras que un ORM miraría en su mapa de identidad y diría: "Oye, ya recuperé ese, no es necesario hacer otro viaje de ida y vuelta". Además, la afirmación de que los procedimientos almacenados se almacenan en caché en el servidor, mientras que SQL ad-hoc no lo es, es un mito que fue reventado por Frans Bouma en su blog: "Stored Procedures are bad, m'kay?"
Los procedimientos almacenados ofrecen poca o ninguna ventaja en términos de seguridad, y no lo protegen contra las vulnerabilidades de inyección de SQL.El caso en cuestión:
Por supuesto, se puede escribir procedimientos que no tienen vulnerabilidades de inyección SQL almacenado, pero se puede igualmente escribir SQL ad-hoc en su capa de negocio que no tiene vulnerabilidades de inyección de SQL, mediante consultas parametrizadas. Atribuir protección contra la inyección SQL a los procedimientos almacenados, en lugar de no romper cadenas de SQL juntas, es una pista falsa y totalmente engañosa.
Si no sabe qué procedimientos almacenados actualizar cuando cambia su base de datos, eso no es un problema con los procedimientos almacenados, es un problema con quien esté a cargo de la DB – MartW
Estaba pensando lo mismo, pero no lo hice tener el corazón para decirle. – tster
'Ver dependencias' funciona bastante bien para mí, al igual que interrogar a las tablas del sistema. Mucho más fácil que pescar con arrastre para el código de la aplicación para una declaración ACTUALIZADA que está compuesta sobre la marcha. – MartW