sql server - stored - Procedimientos almacenados-Fin de días
procedimientos almacenados sql (20)
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?
¡Bah!
ORM, SP, View, Magic Wands, o lo que sea.
Cada "herramienta" tiene su lugar en su cinturón, use las herramientas que tenga con prudencia.
Lo único que ha "cambiado" (realmente mejorado) es que algunos ORM tienen buenas herramientas de almacenamiento en caché ya preparadas y MySql y Sql 2005+ pueden manejar el almacenamiento en caché dinámico o ad hoc de planes de ejecución / ejecución.
La posible pérdida de rendimiento al lanzar 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.
¿Podría ser más bien que Jeff Atwood sabe que los procedimientos almacenados estarán disponibles para siempre y que 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" :)
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 usando sea un poco más rápido que un sproc.
Algunos puntos buenos hacen en ambos lados (por así decirlo) pero nadie ha hecho gran parte 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.
Capacidad de mantenimiento 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.
El almacenamiento en caché de rendimiento de las consultas puede estar produciendo un rendimiento cercano a 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.
Depurar Es probablemente bastante fácil con los SP que la depuración de nivel de negocio + nivel de BD juntos.
Puede haber incluso más puntos ve con SP.
Pero al observar la tendencia moderna de la programación, es más bien "inteligente" 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.
Cuando combina SP con lógica con la base de datos en sí, efectivamente convierte el DB en algo similar 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.
Debo agregar que algo de trabajo se hace mejor en el nivel DB.
por ejemplo, resultados de la tabla cruzada en SQL 2005, consultas recursivas.
Estoy de acuerdo en que algunas de las cosas simples como SELECT, INSERT, UPDATE, DELETE pueden ser atendidas por ORM, Linq.
Entonces, 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)?
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.
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 las 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, es posible que desee utilizar procedimientos almacenados para hacer cumplir las reglas comerciales entre aplicaciones.
Esta pregunta también sangra en una publicada hoy .
Los SP probablemente sean el camino a seguir si SOLO te 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.
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.
Los procedimientos / vistas / funciones almacenados 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.
App # 2-10 - Puede o no puede usar este objeto de base de datos
Lo primero que quiero hacer es verificar las dependencias de objetos de mi base de datos para determinar cómo se usa y si voy a romper algo. 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 encuentro tener acceso directo a las tablas.
Para una sola aplicación que utiliza una sola 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.
Los procesos almacenados son útiles para cosas que no son CRUD, como la lógica especializada de tabla cruzada que se ejecuta mejor en el DB. Las operaciones CRUD no deberían usar SP a menos que sean la salida generada automáticamente de una herramienta ORM como TableAdapters.
ORM y LINQ to SQL parecen ser las tendencias actuales para reemplazar StoredProcs.
Personalmente, he usado ORM y me resulta mucho más fácil de mantener y apoyar.
Algunas de las razones indicadas para usar procesos almacenados nunca fueron razones legítimas para comenzar.
Hace un buen punto acerca de tener un procedimiento almacenado cuando da servicio a múltiples aplicaciones; se convierten esencialmente en DAL, generalmente con cierta lógica de negocios allí.
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 coincidencia de impedancias").
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 en el nivel de objetos comerciales.
No son tan útiles si su almacén de datos es xml o una base de datos analítica.
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 LO QUE ES UNA 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 comunique con un DB a través de una herramienta ORM.
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.
También depende de lo que estén haciendo los procedimientos almacenados.
Por ejemplo, si es solo
select a from b where x = y
entonces un procedimiento almacenado es probablemente 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 mis casos, puedo ver un beneficio al usarlos. 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 será mejor que un proyecto de mala calidad sin y viceversa.
tal vez soy demasiado viejo, demasiado perezoso, o ambos, pero tengo que estar en desacuerdo. Una y otra vez, los procedimientos almacenados han ''guardado el día'' porque cuando aparece un pequeño cambio en el back-end o error , 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, el problema de la actualización del cliente-aplicaciones se mitiga (gracias a maud-dib), pero los procedimientos almacenados que se llaman entre sí son aún más eficientes que los múltiples viajes redondos a la capa SOA. Y la actualización de la capa SOA tampoco siempre es trivial.