Eficiencia de procedimientos almacenados frente a consultas sin procesar

He leído mucho en ambos lados de este debate: ¿hay una ganancia de rendimiento significativa al usar solo procedimientos almacenados sobre consultas sin procesar? Estoy específicamente interesado en SQL Server pero estaría interesado en todas y cada una de las bases de datos.

Es menos en SQL Server 2008 y superior, pero todavía está allí. Todo se reduce a que el caché del plan de ejecución y SQL Server pueden parametrizar automáticamente las consultas que se envían. Cuando se utilizan procedimientos almacenados (que no tienen SQL dinámico dentro de ellos) las consultas ya están parametrizadas, por lo que SQL Server no No es necesario generar un plan para cada consulta cuando se ejecuta, ya que los planes ya están almacenados en la caché del plan.

Y no se olvide de los problemas de seguridad (SQL dinámico, permisos mínimos, etc.) que desaparecen al usar procedimientos almacenados.

Cuando la aplicación usa SQL dinámico contra las tablas base para seleccionar, insertar, actualizar y eliminar los datos en las tablas, la aplicación necesita tener derechos sobre todos esos objetos directamente. Entonces, si alguien usa la Inyección SQL para ingresar al servidor, tendrá derechos para consultar, cambiar o eliminar todos los datos en esas tablas.

Si está utilizando procedimientos almacenados, solo tienen los derechos para ejecutar los procedimientos almacenados recuperando solo la información que devolvería el procedimiento almacenado. En lugar de emitir una declaración de eliminación rápida y eliminar todo, tendrían que averiguar qué procedimientos se pueden usar para eliminar datos y luego averiguar cómo usar el procedimiento para hacerlo.

Dado que la inyección SQL es la forma más fácil de ingresar a una base de datos, esto es algo importante.

Como una adición a la respuesta de Denny, no es raro encontrar sistemas en los que se desperdicia una memoria de agrupación de almacenamiento intermedio significativa en planes de ejecución ad-hoc de uso único o de bajo uso, creados como resultado de consultas que se utilizan en procesos.

Los peores casos últimamente, 8GB asignados a una instancia, caché de plan de 3GB, planes de uso único de 2.5GB. La mayoría de estos han sido SQL2005, por lo que no ha sido una opción intentar optimizar la configuración de cargas de trabajo ad-hoc.

Ciertamente, es cada vez más difícil incluir el rendimiento en una justificación de procedimientos sobre consultas sin procesar. Uno de los argumentos más sólidos para mí ahora es "Si usa procedimientos, es mucho más fácil para mí ayudar cuando surgen problemas de rendimiento". Una interfaz dinámica / linq / orm no le impide ajustar, pero puede limitar severamente sus opciones.

SQL Server almacena en caché y optimiza los procedimientos almacenados y SQL ad-hoc de la misma manera. Por ejemplo, este procedimiento:

create procedure dbo.TestSB(@id int) as select * from Orders where id = @id

Se optimizará y almacenará en caché de forma idéntica para:

select * from Orders where id = @id

Sin embargo, el siguiente SQL ad-hoc no se puede almacenar en caché de manera efectiva, debido al valor codificado:

select * from Orders where id = 42

Aunque el rendimiento es el mismo, existen buenas razones para usar procedimientos almacenados. Los procedimientos almacenados proporcionan una separación clara entre DBA y los desarrolladores de aplicaciones. Es bueno tener una capa adicional de defensa entre sus datos valiosos y los programas en constante cambio :)