Inconvénient des procédures stockées
Vous souhaitez obtenir une liste des avantages et des inconvénients de l’utilisation des procédures stockées. Le principal avantage des SP semble être une précompilation et une abstraction des données de l'application. Donnez moi vos pensées ....
Correction: leur précompilation dépend de la base de données. Dans SQL Server, par exemple, ils ne le sont pas. Les procédures stockées et le SQL paramétré sont tous deux compilés avant d'être exécutés. Une procédure stockée peut parfois réutiliser un plan d’exécution s’il en existe un ... mais il est également possible de paramétrer SQL.
Edit: Voici ce que MSDN en dit :
SQL Server 2000 et SQL Server version 7.0 intègrent un certain nombre de modifications dans le traitement des instructions qui étendent de nombreux avantages en termes de performances des procédures stockées à toutes les instructions SQL. SQL Server 2000 et SQL Server 7.0 n'enregistrent pas de plan partiellement compilé pour les procédures stockées lors de leur création. Une procédure stockée est compilée au moment de l'exécution, comme toute autre instruction Transact-SQL. SQL Server 2000 et SQL Server 7.0 conservent les plans d'exécution pour toutes les instructions SQL dans le cache de procédures, pas seulement les plans d'exécution de procédures stockées.
Avantages : Fournit une "interface publique" à une base de données (une autre couche d'abstraction).
Regroupe également toutes les requêtes au même emplacement, ce qui permet aux administrateurs de bases de données de voir comment la base de données est interrogée et de l'optimiser en conséquence.
Inconvénients : Peut-être pas le meilleur endroit pour mettre en logique complexe. Cependant, suivant l’idée que la logique complexe appartient au code d’application et non aux procédures stockées, les procédures stockées deviennent simplement des opérations CRUD (chaque table comporte une procédure "Créer", "Lire", "Mise à jour" et "Supprimer"). Dans ce cas, les procédures stockées n'ajoutent aucune valeur à l'application, elles ne font que complexifier la maintenance et deviennent un gaspillage.
Les requêtes sont toutes regroupées, il est donc difficile de voir le contexte de l'application dans laquelle elles sont utilisées. L'analyse de l'impact d'un changement est plus longue, et le changement est aussi plus long.
Par conséquent : utilise des procédures stockées pour encapsuler des requêtes complexes (jointures complexes, clauses where complexes, ...). Mais n'utilisez pas de procédure stockée pour une application/domaine/logique métier complexe, et n'utilisez pas non plus de procédures stockées pour CRUD. Les procédures stockées doivent donc être utilisées dans une minorité de cas plutôt que d'être l'outil standard pour toutes les requêtes d'une application.
Code de groupe (y compris les requêtes) pour obtenir une "cohésion fonctionnelle" au lieu d'un regroupement par outil/technologie. Pour permettre à un administrateur de base de données d'optimiser une base de données en fonction de la manière dont elle est interrogée, utilisez un profileur.
En utilisant les SP, vous évitez également de donner aux utilisateurs un accès direct aux tables. Tous les accès peuvent être contrôlés via les SP.
Désavantages
Le refactoring est plus difficile. Renommer ou modifier l'emplacement de la procédure stockée peut avoir un effet négatif.
Les procédures stockées de test unitaire nécessitent l'assistance de code en dehors de la base de données
Avantage
- Vous n'avez pas besoin de déployer pour faire un changement.
- Plus rapide parfois
- Plus facile d'étendre un système
Avec les bibliothèques d'infrastructure .Net 3.5 actuelles, j'utiliserais Linq pour effectuer la plupart des opérations de base de données. Il peut y avoir des endroits où SP a plus de sens. Mais Linq a également prévu de lancer un SP.
En ce qui concerne les inconvénients de SP, consultez le lien suivant - une analyse intéressante. Vérifiez également les commentaires de l'article.
http://www.spoiledtechie.com/post/Whats-up-with-Stored-Procedures-these-days.aspx
Avantage: les procédures stockées peuvent être utilisées pour maintenir l'intégrité des données et appliquer la stratégie de base de données sans recourir à un programme externe.
Inconvénient: peut rendre le débogage plus complexe. Peut également être sensible à l’abandon lors des opérations de copie, s’il n’est pas effectué correctement.
Désavantages
- Le contrôle de la source peut être une douleur.
- Le débogage est difficile.
- Si vous avez beaucoup de fonctionnalités dans procs, il sera plus difficile de permuter entre différents systèmes de base de données. Cela créera également plus de travail si vous souhaitez prendre en charge différents systèmes de base de données.
- Le développement de procédures stockées peut être une tâche assez spécialisée, en particulier à mesure qu’elles deviennent plus complexes.
Le contrôle de version constitue un autre inconvénient, car une partie de la logique métier se trouve maintenant dans la base de données. Pouvez-vous facilement revenir à la v1 (il y a un an) de la v2 (maintenant)?
Une solution réalisable est la gestion des versions des noms de procédures stockées. Mais maintenant, la base de données est un gâchis d'anciennes et de nouvelles procédures stockées.
Quelques raisons pour lesquelles j'utilise des procédures stockées exclusivement lors de la création d'applications:
- Les procédures stockées peuvent être l'interface entre votre application et la base de données sous-jacente. Ainsi, le serveur sur lequel réside la base de données, qui est généralement plus puissant qu'un ordinateur de bureau, peut être utilisé pour effectuer des procédures plus complexes.
- Si vous devez modifier la structure de la base de données, vous pouvez le faire sans interrompre votre application si des procédures stockées sont utilisées comme interface.
- Au fur et à mesure que vous écrivez, les procédures stockées contiennent du SQL précompilé et pré-testé.
- Il est plus facile d'effectuer des opérations complexes avec des procédures stockées qu'avec du code SQL généré par le client ou l'interface graphique.
L’avantage de l’utilisation des procédures stockées par rapport à l’écriture de la même logique dans le code de l’application est qu’elle permet de réduire le nombre d’appels effectués par la base de données.
Une procédure stockée peut prendre ses arguments et prendre différentes décisions et actions en fonction de ces arguments au lieu de renvoyer un résultat à l'application, puis l'application prend une décision et décide qu'elle doit effectuer une autre action et effectuer un autre appel de base de données.
Le goulot d'étranglement dans la performance est presque toujours une communication inter-processus. J'essaie de faire le minimum d'appels à la base de données.
Avantage: l'administrateur de base de données peut ajouter un comportement qui ne tient pas à l'application. Par exemple, stocker une date de modification sur chaque ligne.
Avantage: le code lié à votre base de données a plus de chances d’être écrit par du personnel intéressé et qualifié pour le travail dans la base de données.
Avantage: l'équipe des opérations dispose d'un crochet pour surveiller ou résoudre les problèmes en production.
Avantages: les SP sont utilisés pour exécuter un ensemble d'instructions SQL. Inconvénients: le débogage est complexe
Un autre avantage peut être dans les environnements de grande entreprise où vous pouvez avoir plusieurs applications et environnements clients (tels que des outils Web, de bureau et de reporting répartis sur différents systèmes d'exploitation) qui utilisent la base de données. Pour certaines modifications de règles métier, des modifications peuvent être apportées à la base de données, ce qui est efficace dans tous les environnements.
Avantages -
- Organisé en un seul endroit (non éparpillé sur le code)
- Beaucoup plus rapide que les requêtes dynamiques
Cela augmente la charge sur le serveur. Si d'autres applications ou plusieurs applications utilisent le même serveur de base de données, celles-ci deviennent lentes.
la réponse simple serait la suivante: adv: il s’agit de la structure la plus puissante pour encapsuler des codes T-SQL. il n'est pas limité à SELECT et prend en charge tous les codes DML. il permet de recevoir les entrées et de renvoyer les sorties directement.
dis: il n'est pas possible de l'appeler dans SELECT, vous ne pouvez donc pas l'exécuter pour plusieurs enregistrements.