Procédures stockées contre. Des vues
J'ai utilisé les deux, mais ce que je ne sais pas, c'est quand je devrais en préférer un. Je veux dire que je sais que la procédure stockée peut prendre des paramètres ... mais vraiment, nous pouvons toujours effectuer la même chose en utilisant des vues aussi, non?
Donc, en considérant la performance et d’autres aspects quand et pourquoi devrais-je préférer l’un l’autre?
Eh bien, j'utiliserais mieux les procédures stockées pour l'encapsulation du code et le contrôle des autorisations.
Une vue n'est pas vraiment une encapsulation: c'est une macro qui se développe. Si vous commencez à rejoindre des vues très bientôt, vous aurez des questions épouvantables. Oui, ils peuvent être joints, mais ils ne devraient pas ..
En disant cela, les vues sont un outil qui a sa place (vues indexées par exemple) comme les procs stockées.
L'avantage des vues est qu'elles peuvent être traitées comme des tables. Vous pouvez utiliser WHERE pour obtenir des données filtrées à partir d’eux, joindre en eux, et cetera. Vous pouvez même y insérer des données si elles sont assez simples. Les vues vous permettent également d’indexer leurs résultats, contrairement aux procédures stockées.
Une vue est comme une instruction de requête enregistrée, elle ne peut pas contenir une logique complexe ou plusieurs instructions (au-delà de l'union, etc.). Pour tout ce qui est complexe ou personnalisable via des paramètres, vous choisirez des procédures stockées qui offrent une plus grande flexibilité.
Il est courant d'utiliser une combinaison de vues et de procédures stockées dans une architecture de base de données, et peut-être pour des raisons très différentes. Parfois, il s'agit d'assurer la compatibilité ascendante des sprocs lors de la refonte du schéma, parfois de rendre les données plus faciles à manipuler par rapport à la manière dont elles sont stockées de manière native dans des tables (vues non normalisées).
Une utilisation intensive de Views peut dégrader les performances, car SQL Server a plus de difficultés à optimiser ces requêtes. Cependant, il est possible d'utiliser des vues indexées qui peuvent réellement améliorer les performances lorsque vous travaillez avec des jointures de la même manière que des tables indexées. Il existe des restrictions beaucoup plus strictes sur la syntaxe autorisée lors de l'implémentation de vues indexées et de nombreuses subtilités pour les faire fonctionner en fonction de l'édition de SQL Server.
Considérez les vues plus comme des tables que des procédures stockées.
Le principal avantage des procédures stockées est qu’elles vous permettent d’intégrer une logique (script). Cette logique peut être aussi simple qu’un IF/ELSE ou plus complexe telle que des boucles DO WHILE, SWITCH/CASE.
Je corrèle l'utilisation de procédures stockées à la nécessité d'envoyer/recevoir des transactions depuis et vers la base de données. Autrement dit, chaque fois que je dois envoyer des données à ma base de données, j'utilise une procédure stockée. Il en va de même lorsque je souhaite mettre à jour des données ou interroger la base de données pour des informations à utiliser dans mon application.
Les vues de base de données sont très utiles lorsque vous souhaitez fournir un sous-ensemble de champs d’une table donnée, autorisez vos utilisateurs MS Access à afficher les données sans risque de les modifier et à vous assurer que vos rapports généreront les résultats anticpés.
Les vues sont utiles s'il existe une certaine combinaison de tables ou un sous-ensemble de données que vous souhaitez systématiquement interroger, par exemple un utilisateur associé à ses autorisations. Les vues doivent en fait être traitées comme des tables.
Les procédures stockées sont des morceaux de code SQL qui sont «compilés», pour ainsi dire, de manière à être exécutés de manière plus optimale qu'une requête aléatoire. Le plan d'exécution du code SQL dans une procédure stockée est déjà construit. L'exécution est donc légèrement plus fluide que celle d'une instruction SQL ordinaire.
Deux raisons.
Utilisez la procédure stockée au lieu de la vue si vous ne voulez pas que l'insertion soit possible. L'insertion dans une vue peut ne pas donner ce qu'elle semble faire. Il insérera dans une table, une ligne qui peut ne pas correspondre à la requête de la vue, une ligne qui n'apparaîtra pas dans la vue; inséré quelque part, mais pas où la déclaration semble-t-il.
Utilisez une vue si vous ne pouvez pas utiliser le résultat d'une procédure stockée à partir d'une autre procédure stockée (je n'ai jamais réussi à faire en sorte que cette dernière fonctionne, du moins avec MySQL).