Procedimientos almacenados - Fin de días

Question

Estoy escuchando el Podcast de Hanselminutes; "StackOverflow utiliza ASP.NET MVC - Jeff Atwood y su equipo técnico". Durante el curso del Podcast están hablando de SQL Server y dicen algo como "Los días del procedimiento almacenado se han terminado".

Ahora no soy un DBA, pero esto me ha tomado un poco por sorpresa. Siempre asumí que los SP eran el camino a seguir por la velocidad (a medida que se cumplen) y la seguridad, sin mencionar la escalabilidad y la facilidad de mantenimiento. Si este no es el caso y los SP están en sus últimas etapas, ¿qué los reemplazará o qué deberíamos estar haciendo en el futuro?

Answer 1

En los sistemas modernos, las consultas parametrizadas se compilan y almacenan en caché en el servidor, por lo que son tan rápidas como un procedimiento almacenado. Ellos tienen la mayoría de las mismas características de seguridad también.

Para bases de datos que sirven una sola aplicación, tiene más sentido tener la lógica de consulta allí en la ubicación relevante en el código. Si nada más hace que sea más fácil hacer control de fuente. Si mantiene los procedimientos almacenados en el servidor, el seguimiento de ellos puede convertirse rápidamente en un desastre. Además, si está utilizando una herramienta ORM, puede que no tenga mucho en el camino de SQL real de todos modos.

Si su base de datos sirve varias aplicaciones diferentes, entonces aún puede desear usar procedimientos almacenados para hacer cumplir las reglas comerciales entre aplicaciones.

Answer 2

SPs son probablemente el camino a seguir si SÓLO le preocupa la velocidad. Pero si le preocupa la escalabilidad o el mantenimiento, los SP pueden no ser los mejores. Nuestra arquitectura se basa en SP y después de 10 años de código, es muy difícil de mantener y muy defectuoso. Un buen mapeador ORM podría ser una mejor opción.

Answer 3

Diría que los SP no se pueden mantener y no se escalan. Pregunte a cualquier desarrollador que haya tenido que agregar funcionalidad a un sistema SP pesado. ¿Por qué tienes la mitad de tu lógica en una capa diferente? No hay nada para reemplazar, simplemente no los use.

Googled this great post.

Answer 4

ORM y LINQ a SQL parecen ser las tendencias actuales para reemplazar StoredProcs.

Yo personalmente he usado ORM y me resulta mucho más fácil de mantener y de dar soporte.

Algunas de las razones indicadas para usar procesos almacenados donde nunca son razones legítimas para empezar.

Hace un buen punto acerca de tener un procedimiento almacenado cuando da servicio a varias aplicaciones; se convierten esencialmente en DAL, generalmente con cierta lógica de negocios allí.

Answer 5

tal vez soy demasiado viejo o demasiado flojo, o ambos, pero no estoy de acuerdo. Una y otra vez, los procedimientos almacenados han 'guardado el día' porque cuando aparece un error menor en el componente , solo tenemos que arreglar el procedimiento almacenado en lugar de actualizar la aplicación de escritorio en varias docenas de escritorios más el servidor web. Además, los usuarios no son interrumpidos. Esto ahorra una gran cantidad de esfuerzo y molestias al usuario.

Además, algunas operaciones DB serán más eficientes en el servidor en lugar de ir y venir a través de la red, especialmente. cuando un procedimiento almacenado llama a otro que llama a otro, etc. (con o sin cursores)

EDITAR: en una arquitectura SOA, la cuestión de la actualización del cliente-aplicaciones se mitiga (gracias maud-dib), pero los procedimientos almacenados llaman a cada otro es aún más eficiente que múltiples viajes redondos a la capa SOA.Y la actualización de la capa SOA tampoco siempre es trivial.

Answer 6

También depende de lo que estén haciendo los procedimientos almacenados.

Por ejemplo si es sólo

select a from b where x = y 

a continuación un procedimiento almacenado es algo excesivo. Pero yo personalmente tiendo a usar procs almacenados para devolver múltiples conjuntos de resultados y resultados de página dentro de la base de datos.

En mi caso, puedo ver un beneficio de su uso. Es una capa extra para tratar, pero si tienes tu código bien organizado y lógico, no veo demasiada molestia personalmente.

Un buen proyecto con procedimientos almacenados siempre va a ser mejor que un proyecto de mala calidad sin y viceversa.

Answer 7

Solo lanzando mi pequeño consejo aquí. Antes de SQL 2005 (tal vez incluso más que eso), SP era más rápido. Sin embargo, SQL Server 2005 y versiones posteriores están realmente optimizados y guardan sus consultas sobre la marcha. De hecho, tuvimos una aplicación web transferida a un nuevo servidor SQL. La aplicación comenzó a funcionar ralentizando para todos. Todo estaba tomando "3/4 de segundo" o 1 segundo para correr. Entonces SQL comenzó a compilar la consulta más utilizada y todo pasó de lento a rápido.

Por supuesto, intercambiamos el servidor mientras había mucha gente corriendo (lo que puede explicar por qué fue lento al principio). Pero confía en mí SP no ha terminado. Simplemente tienen otros usos que estar vinculados a una aplicación.

Answer 8

Esta pregunta también sangra en one posted earlier today.

Answer 9

Cuando combina SP con lógica con la base de datos en sí, convierte efectivamente la base de datos en algo parecido a un servidor de aplicaciones.

Cuando este era el martillo más útil, tenía mucho sentido. Pero ahora, con la disponibilidad ubicua de Servidores de aplicaciones, tiene más sentido aprovecharlos para cosas como la lógica centralizada y las reglas de negocio y confiar en la base de datos solo para la persistencia.

Answer 10

A juzgar por el desempeño deslucido de este sitio, voy a apostar que el mayor cuello de botella es la base de datos.

No estoy convencido de ninguna manera de que el LINQ 2 SQL ORM que están utilizando sea un poco más rápido que un sproc.

Answer 11

Los SP se usan generalmente demasiado pronto en el proceso de desarrollo. Deben usarse cuando tenga una declaración sql de cuello de botella. Por ejemplo, probablemente no necesite un SP para eliminar o crear usuarios para una aplicación. Para la mayoría de empresas que deberían ser bastante estáticas.

Answer 12

Sigo escuchando el argumento de que los SP son buenos si tiene múltiples aplicaciones conectadas a la base de datos o que facilita la corrección de errores.

¡ESTO ES PARA QUÉ ES LA CAPA DE SERVICIO!

La lógica empresarial va en la capa de servicio, la lógica de la aplicación va en la aplicación/sitio web.

Es mucho más difícil depurar y mantener cientos de SP (especialmente si se generan) que mantener un código bien escrito que se comunica con un DB a través de una herramienta ORM.

Answer 13

Maintabilidad Probablemente los SP sean mejores. Si mantener cientos de SP es difícil, es aún más difícil mantenerlos en los componentes del nivel empresarial.

Rendimiento El almacenamiento en caché de las consultas puede estar produciendo un rendimiento cercano al SP. Pero no pueden igualar el rendimiento de los SP en distintas variedades de bases de datos en variedades de plataforma. La latencia de la red es otra área de preocupación, aunque la brecha se está reduciendo en la actualidad.

Debug Probablemente sea bastante fácil con los SP que depurando el nivel de negocio + nivel de db juntos.

Puede haber incluso más puntos con los SP.

Pero al observar la tendencia moderna de la programación, es más bien "sabio" ir con la arquitectura 'N' por muchas razones comerciales que seguir con el enfoque "antiguo" basado en SP.

Un buen sistema debería tener una combinación de ambos. Probablemente siguiendo el principio 80-20, siendo 20 SP.

Answer 14

¿Podría ser más bien que Jeff Atwood sabe procedimientos almacenados estarán por siempre y simplemente estaba tratando de estimular el pensamiento y el debate? Me gusta pensar que lo que realmente le gustaría hacer es escribir un ensayo persuasivo titulado "Procedimientos almacenados considerados dañinos" :)

Answer 15

Algunos puntos buenos hacen en ambos lados (por así decirlo) pero nadie ha hecho mucho de la implicación de seguridad. Al agrupar toda la interacción DB en SP, significa que puede bloquear la base de datos para que cualquier interacción con los datos pueda controlarse estrechamente.

Si piensa en la encapsulación, puede considerar la base de datos como un objeto y los SP como métodos y propiedades que exponen la funcionalidad de los objetos al mundo exterior.

En algunos entornos de desarrollo más grandes, los desarrolladores de la capa de negocios y UI no están permitidos cerca de la base de datos. Especifican sus requisitos y el equipo separado proporciona una interfaz a través de SP.

Existen algunas buenas razones para no usar los SP y algunas buenas razones para usarlos solo dependen de su aplicación y su entorno. Pero tenga la seguridad de que los SP no irán a ningún lado pronto.

Answer 16

Podría agregar que algo de trabajo se hace mejor en el nivel de base de datos.
p. Resultados de la tabla cruzada en SQL 2005, consultas recursivas.

Acepto que algunas de las cosas simples como SELECT, INSERT, UPDATE, DELETE pueden ser atendidas por ORM, Linq.

Por lo tanto, es estúpido decir que los días de procedimientos almacenados han terminado.
¿Cuántas personas realmente tienen que preocuparse por los cambios de la plataforma DB (SQL a Mysql, Oracle)?

Answer 17

Parte de esto se debe a la disponibilidad de almacenes de datos no relacionales. Los SP generalmente implican una base de datos relacional; ORM y Linq ofrecen la capacidad de crear capas de abstracción que son más ricas que las ofertas de SQL, y a veces una mejor coincidencia para las abstracciones que usamos en otras partes del diseño (el problema de "falta de adecuación de impedancia").)

Y también se puede considerar una función de la arquitectura. Los SP coinciden bastante bien con una aplicación clásica basada en tablas, y pueden proporcionar una forma conveniente de diseñar una capa de abstracción a nivel de objetos de negocio.

No son tan útiles si su almacén de datos es xml o una base de datos analítica.

Answer 18

Bah!

ORM, SP, Vista, Magic Wands, o lo que sea.

Cada "herramienta" tiene su lugar en su cinturón, utilice las herramientas que tenga con prudencia.

Lo único que ha "cambiado" (realmente mejorado) es que algunos ORM tienen buenas herramientas de almacenamiento en caché y MySql y Sql 2005+ pueden manejar el almacenamiento en caché dinámico o ad hoc.

La posible pérdida de rendimiento al arrojar todo tipo de sql dinámico en su servidor de db se ha mitigado un tanto. Simplemente es más fácil ir sin procedimientos almacenados ahora. Los Provisos almacenados no van a ir a ningún lado.

Answer 19

Procedimientos almacenados/Vistas/Las funciones siguen siendo una buena "interfaz" para la base de datos si está ejecutando varias aplicaciones empresariales que comparten la misma base de datos.

Aplicación n. ° 1: debe agregar una nueva relación/campo, o cambiar una columna que admite nulos por nula.

Aplicación # 2-10 - puede o no puede utilizar este objeto de base de datos

La primera cosa que quiero hacer es comprobar mis dependencias de objetos de base de datos para determinar cómo la utiliza y si voy a romper nada. Bueno, adivina qué, si tienes un montón de consultas externas VIA ORM/SQL no tendrías ni idea de las dependencias.

Este es el único inconveniente que encontré al tener acceso directo a las tablas.

Para una sola aplicación que utiliza una única base de datos, esto realmente no es un problema. Aunque todavía tiene que mirar el código de la aplicación para las dependencias además de la base de datos.

Answer 20

Los objetos almacenados son útiles para cosas que son no CRUD - como la lógica especializada de tabla cruzada que se ejecuta mejor en la base de datos. Las operaciones CRUD no deberían usar SP a menos que sean la salida generada automáticamente de una herramienta ORM como TableAdapters.