.net - parametros - ejecutar procedimiento almacenado mvc 5
¿Todavía necesitamos procedimientos almacenados cuando usamos consultas compiladas? (3)
"¿Hay alguna situación en la que los procedimientos almacenados tengan un rendimiento significativamente mejor?"
Dada una pieza comparable de SQL parametrizado generado en EF o en un proceso almacenado, funcionarán por igual.
Sin embargo, un DBA siempre tiene la oportunidad de optimizar aún más una consulta en función de su experiencia con el esquema DB y sus patrones de uso. Un procedimiento almacenado les permite hacer esto fácilmente en forma aislada de las aplicaciones que lo usan, mientras que un ORM no lo hace.
Tenemos un DB de SQL Server extremadamente complicado que tiene muchos sistemas externos que replican datos dentro y fuera a través de desencadenantes. El problema para nosotros con EF es que la responsabilidad del SQL que se dispara en el DB se convertirá en responsabilidad de los desarrolladores de la aplicación al usar cualquier ORM en lugar de los DBA.
Cuando se utilizan consultas compiladas en el marco de la entidad (o linq-to-sql) en combinación con SQL Server, ¿hay todavía algún beneficio de rendimiento en el uso de procedimientos almacenados?
Las consultas compiladas se almacenarán en caché como consultas parametrizadas, por lo que el rendimiento debería ser casi igual a los procedimientos almacenados. ¿Hay alguna situación en la que los procedimientos almacenados tengan un rendimiento significativamente mejor?
- EDITAR -
En respuesta a la respuesta de Yakimych a continuación, no quise dar a entender que las consultas compiladas son las mismas que las de los procedimientos almacenados. Estoy tratando de averiguar si todavía son necesarios los spro si has realizado todas las optimizaciones posibles en el lado de la aplicación (en este caso, las consultas compiladas). Así que supongo que estoy buscando razones por las que un procedimiento almacenado sería mejor que la combinación de optimizaciones del lado de la aplicación y consultas parametrizadas (que es lo que efectivamente son las consultas compiladas).
Una de las razones por las que estoy preguntando esto es porque hay muchas personas que parecen pensar que las acciones almacenadas ya no son necesarias por diferentes razones (es decir, esta publicación ).
Algunas respuestas enlatadas de expertos reconocidos: Paul Nielsen ¿Por qué utilizar procedimientos almacenados?
Adam Machanic: No, los procedimientos almacenados NO son malos
En primer lugar, la compilación de consultas EF no tiene nada que ver con los beneficios de rendimiento que se pueden lograr mediante el uso de procedimientos almacenados.
De acuerdo con http://msdn.microsoft.com/en-us/library/cc853327.aspx , las siguientes operaciones ocurren cuando una consulta se ejecuta en un modelo conceptual:
- Cargando metadatos
- Abriendo la conexión de la base
- Generando vistas
- Preparación de la consulta
- Ejecutando la consulta
- Carga y validación de tipos
- Rastreo
- Materializar los objetos
Y la explicación con respecto a la Preparing the query :
Incluye los costos para componer el comando de consulta, generar un árbol de comandos basado en metadatos de mapeo y modelo, y definir la forma de los datos devueltos. Debido a que los comandos de consulta de Entity SQL están en caché, las ejecuciones posteriores de la misma consulta toman incluso menos tiempo. También puede usar consultas compiladas LINQ para reducir este costo en ejecuciones posteriores.
Por lo tanto, si compila la consulta y la vuelve a usar más adelante, lo que sucede es que ahorra tiempo en esta operación en su aplicación durante cada ejecución posterior de la consulta. Sin embargo, lo que no hace es no influir en el código SQL generado que se ejecuta en la base de datos. Los beneficios de rendimiento que obtiene al compilar las consultas son a nivel de la aplicación.
Por otro lado, normalmente utilizaría procedimientos almacenados en caso de que no esté satisfecho con el código SQL generado y desee optimizar el rendimiento en el nivel de la base de datos.
EDITA en respuesta a tu comentario y edición.
Me parece que tiene la impresión de que la compilación de una consulta EF de alguna manera cambiaría el código SQL generado que se ejecutará contra la base de datos (¿menciona que las consultas compiladas dan como resultado consultas SQL parametrizadas?). Ese no es el caso. No importa si ejecuta la consulta directamente o usa compiledQuery.Invoke , el mismo código SQL se ejecutará contra el DB . Además, no tienes control total sobre él, más bien dependes del ORM para generarlo de la mejor manera posible. En algunos casos, no es óptimo, y aquí es donde entran los SP.
Así que para resumir:
- La compilación de consultas es puramente una optimización del lado de la aplicación. Ahorra tiempo para compilar una consulta que se vuelve a utilizar en el código.
- Los procedimientos almacenados se pueden usar para ajustar su código SQL y conseguir que coincida con su objetivo lo más cerca posible, lo que brinda la posibilidad de obtener el mejor rendimiento a nivel de la base de datos.
De ninguna manera es una técnica un sustituto de la otra.