Efficacité des procédures stockées par rapport aux requêtes brutes

J'ai beaucoup lu des deux côtés de ce débat: y a-t-il un gain de performance significatif à avoir en utilisant uniquement des procédures stockées sur des requêtes brutes? Je suis spécifiquement intéressé par SQL Server mais je serais intéressé par toutes les bases de données.

C'est moins le cas dans SQL Server 2008 et supérieur, mais il est toujours là. Il s'agit du cache du plan d'exécution et de SQL Server pouvant paramétrer automatiquement les requêtes qui sont envoyées. Lorsque vous utilisez des procédures stockées (qui ne contiennent pas de SQL dynamique), les requêtes sont déjà paramétrées, donc SQL Server ne fonctionne pas. Vous n'avez pas besoin de générer un plan pour chaque requête lorsqu'elle est exécutée car les plans sont déjà stockés dans le cache de plan.

Et n'oubliez pas les problèmes de sécurité (SQL dynamique, autorisations minimales, etc.) qui disparaissent lors de l'utilisation de procédures stockées.

Lorsque l'application utilise du SQL dynamique par rapport aux tables de base pour sélectionner, insérer, mettre à jour et supprimer les données dans les tables, l'application doit avoir des droits sur tous ces objets directement. Donc, si quelqu'un utilise SQL Injection pour accéder au serveur, il aura le droit d'interroger, de modifier ou de supprimer toutes les données de ces tables.

Si vous utilisez des procédures stockées, ils n'ont que les droits pour exécuter les procédures stockées en récupérant uniquement les informations que la procédure stockée retournerait. Au lieu d'émettre une instruction de suppression rapide et de tout emporter, ils devraient déterminer quelles procédures peuvent être utilisées pour supprimer des données, puis déterminer comment utiliser la procédure pour le faire.

Étant donné que l'injection SQL est le moyen le plus simple de pénétrer dans une base de données, c'est assez important.

En complément de la réponse de Denny, il n'est pas rare de trouver des systèmes où une mémoire tampon importante est gaspillée dans des plans d'exécution ad hoc à usage unique ou à faible utilisation, créés à la suite de requêtes utilisées sur procs.

Pires cas récemment, 8 Go alloués à une instance, 3 Go de cache de plan, 2,5 Go de plans à usage unique. La majorité d'entre eux ont été SQL2005, il n'a donc pas été possible d'essayer le paramètre d'optimisation pour les charges de travail ad hoc.

Il devient certainement plus difficile d'inclure les performances dans une justification des procédures par rapport aux requêtes brutes. L'un des arguments les plus solides pour moi maintenant est "Si vous utilisez des procédures, il est beaucoup plus facile pour moi d'aider lorsque des problèmes de performances surviennent". Une interface dynamique / linq / orm ne vous empêche pas de régler, mais elle peut sérieusement limiter vos options.

SQL Server met en cache et optimise les procédures stockées et le SQL ad hoc de la même manière. Par exemple, cette procédure:

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

Sera optimisé et mis en cache de manière identique pour:

select * from Orders where id = @id

Cependant, le SQL ad-hoc suivant ne peut pas être mis en cache efficacement, en raison de la valeur codée en dur:

select * from Orders where id = 42

Bien que les performances soient les mêmes, il existe de bonnes raisons d'utiliser des procédures stockées. Les procédures stockées offrent une séparation claire entre DBA et les développeurs d'applications. Il est bon d'avoir une couche de défense supplémentaire entre vos données précieuses et les programmes en constante évolution :)