L'utilisation ou non des procédures stockées relève plus d'une discussion religieuse ou politique dans un bar que non.
Ce qu'il faut faire, c'est définir clairement vos couches d'application et ne pas dépasser ces limites. Les procédures stockées présentent plusieurs avantages et inconvénients par rapport aux requêtes en dehors de la base de données.
Avantage 1 :Les procédures stockées sont modulaires. C'est une bonne chose du point de vue de l'entretien. Lorsque des problèmes de requête surviennent dans votre application, vous conviendrez probablement qu'il est beaucoup plus facile de dépanner une procédure stockée qu'une requête intégrée enfouie dans de nombreuses lignes de code GUI.
Avantage 2 :Les procédures stockées sont paramétrables. En ayant des procédures qui gèrent le travail de la base de données pour votre interface, vous éliminez le besoin de modifier le code source de l'interface graphique pour améliorer les performances d'une requête. Des modifications peuvent être apportées aux procédures stockées - en termes de méthodes de jointure, de tables différentes, etc. - qui sont transparentes pour l'interface frontale.
Avantage 3 :Les procédures stockées résument ou séparent les fonctions côté serveur du côté client. Il est beaucoup plus facile de coder une application graphique pour appeler une procédure que de créer une requête via le code graphique.
Avantage 4 :Les procédures stockées sont généralement écrites par des développeurs/administrateurs de bases de données. Les personnes occupant ces rôles sont généralement plus expérimentées dans l'écriture de requêtes et d'instructions SQL efficaces. Cela permet aux développeurs d'applications GUI d'utiliser leurs compétences sur les éléments de présentation fonctionnels et graphiques de l'application. Si vos employés effectuent les tâches pour lesquelles ils sont les mieux adaptés, vous produirez finalement une meilleure application globale.
Avec tout cela à l'esprit, il y a plusieurs inconvénients.
Inconvénient 1 :les applications qui impliquent une logique métier et un traitement étendus pourraient placer une charge excessive sur le serveur si la logique était entièrement implémentée dans des procédures stockées. Des exemples de ce type de traitement comprennent les transferts de données, les traversées de données, les transformations de données et les opérations de calcul intensives. Vous devez déplacer ce type de traitement vers des composants de processus métier ou de logique d'accès aux données, qui constituent une ressource plus évolutive que votre serveur de base de données.
Inconvénient 2 :ne mettez pas toute votre logique métier dans des procédures stockées. La maintenance et l'agilité de votre application devient problématique lorsque vous devez modifier la logique métier en langage Sp. Par exemple, les applications ISV qui prennent en charge plusieurs SGBDR ne devraient pas avoir besoin de gérer des procédures stockées distinctes pour chaque système.
Inconvénient 3 :L'écriture et la maintenance de procédures stockées est le plus souvent un ensemble de compétences spécialisées que tous les développeurs ne possèdent pas. Cette situation peut introduire des goulots d'étranglement dans le calendrier de développement du projet.
J'ai probablement raté certains avantages et inconvénients, n'hésitez pas à commenter.
