Lorsqu’une application doit exécuter une requête dans une base de données, il est préférable que celle-ci appelle une procédure stockée plutôt que d’envoyer une commande T-SQL construite dans le code de l’application.
Outre l’avantage de sécurité contre les attaques par injection et la maintenabilité du code, voici les autres avantages que cela procure :

– Dès lors qu’on appelle une procédure stockée, on a simplement besoin de spécifier son nom et de lui adjoindre la valeur de ses paramètres.
C’est donc moins coûteux en termes de quantité de données qu’une commande T-SQL complète à envoyer à l’instance SQL Server, si courte soit elle.
Dès lors cela réduit le trafic réseau entre les applications et le serveur.

– Lorsqu’on crée une procédure stockée, celle-ci est compilée en un plan qui demeure dans le cache de procédures, ce qui réduit considérablement le coût de calcul du plan d’une requête, gourmand en ressources processeur.

– L’exécution de requêtes par l’instance elle-même peut s’avérer moins coûteuse pour l’application mais aussi pour le serveur de bases de données.
En effet, si nous devons par exemple insérer une valeur binaire dans une table à travers une requête soumise directement par l’application, il faut dans un premier temps convertir la valeur binaire en une chaîne de caractères, ce qui double donc sa taille.
Lorsque l’instance SQL Server reçoit la requête, elle doit reconvertir la valeur chaîne de caractère vers la valeur binaire, ce qui représente pour les deux partis un surcoût.
L’appel d’une procédure stockée élimine ce problème, puisque les valeurs des paramètres sont conservées sous forme binaire depuis l’application jusque dans les pages de la table de la base de données.

– L’utilisation de procédure stockées permet la réutilisation de code. S’il est clair que cela n’augmente pas les performances, cela augmente la productivité des développeurs qui ont moins de code à produire, et qui passent donc moins de temps à le débugger.

– Le second plus gros avantage à mon sens après le cache de procédures est que le code qu’elles encapsulent, la logique de celles-ci, peut être maintenu sans modifier une seule ligne de code de l’application cliente, s’il n’est pas besoin de modifier les paramètres et la structure de l’ensemble de données produit.

En conclusion, il faut garder à l’esprit que ce n’est pas parce que l’on utilise exclusivement des procédures stockées que l’application sera performante.
Il reste encore parfois à réécrire et souvent à optimiser le code qui est encapsulé par une procédure stockée, pour que celui-ci soit performant et qu’il reste le plus longtemps possible dans le cache de procédures.

ElSuket