J'ai utilisé les deux, mais ce que je ne sais pas, c'est quand je dois préférer l'un à l'autre. Je veux dire que je sais que la procédure stockée peut prendre des paramètres... mais en réalité, nous pouvons toujours effectuer la même chose en utilisant des vues, n'est-ce pas ?
Si l'on considère les performances et les autres aspects, quand et pourquoi devrais-je préférer l'un à l'autre ?
Eh bien, j'utiliserais les procédures stockées pour encapsuler le code et mieux contrôler les permissions.
Une vue n'est pas vraiment une encapsulation : c'est une macro qui s'étend. Si vous commencez à joindre des vues, vous obtiendrez rapidement des requêtes horribles. Oui, elles peut être JOINT mais ils ne devraient pas
Cela dit, les vues sont un outil qui a sa place (les vues indexées par exemple) comme les procs stockés.
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 de celles-ci, JOIN dans celles-ci, etc. Vous pouvez même y INSÉRER des données si elles sont suffisamment simples. Les vues vous permettent également d'indexer leurs résultats, contrairement aux procédures stockées.
Voir ma réponse... ? La mentalité est "nous pouvons avoir une vue qui fait tout cela pour nous", puis vue jointe vue jointe vue = requête horrible sur les tables de base. Je l'ai déjà vu et corrigé plusieurs fois. Et répondu à des questions à ce sujet aussi stackoverflow.com/search?q=user%3A27535+macro%2Bview
Oui, mais une vue sert-elle à encapsuler ou à joindre ? La jonction à elle seule n'est pas une raison suffisante. Si vous avez des vues si simples que la jonction n'est pas un problème, pourquoi ne pas utiliser des tables de base ? On abuse trop souvent des vues.
Ces arguments contre les VIEWs semblent faibles et reposent soit sur des généralisations générales, soit sur un mauvais planificateur de requêtes. Regardez le côté opposé de la médaille, les critiques pensent que l'utilisation d'une procédure stockée pour remplacer un VIEW est une bonne idée juste parce que cela ne peut pas être utilisé dans un JOIN. Cela semble assez fou.
Une vue est comme une seule déclaration de requête enregistrée, elle ne peut pas contenir de logique complexe ou de déclarations multiples (au-delà de l'utilisation de l'union, etc.). Pour tout ce qui est complexe ou personnalisable via des paramètres, il faut choisir des procédures stockées, qui offrent une bien 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 ce pour des raisons peut-être très différentes. Parfois, il s'agit d'assurer une compatibilité ascendante dans les sprocs lorsque le schéma est remanié, parfois de rendre les données plus manipulables par rapport à la façon dont elles sont stockées nativement dans les tables (vues dé-normalisées).
Une utilisation intensive des vues peut dégrader les performances car il est plus difficile pour SQL Server d'optimiser ces requêtes. Cependant, il est possible d'utiliser des vues indexées qui peuvent réellement améliorer les performances en travaillant avec des jointures de la même manière que les tables indexées. Il existe des restrictions beaucoup plus strictes sur la syntaxe autorisée lors de l'implémentation des vues indexées et beaucoup de subtilités pour les faire fonctionner en fonction de l'édition de SQL Server.
Les vues s'apparentent davantage à des tableaux qu'à des procédures stockées.
Je fais la corrélation entre l'utilisation des procédures stockées et la nécessité d'envoyer et de recevoir des transactions vers et depuis la base de données. Autrement dit, chaque fois que j'ai besoin d'envoyer des données à ma base de données, j'utilise une procédure stockée. Il en va de même lorsque je veux mettre à jour des données ou interroger la base de données pour obtenir 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, permettre à vos utilisateurs MS Access de visualiser les données sans risquer de les modifier et vous assurer que vos rapports vont générer les résultats escomptés.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
7 votes
Vous devez inclure les fonctions définies par l'utilisateur dans vos réflexions.
0 votes
Il semble que ce soit un doublon de celui-ci : Quels sont les avantages et les inconvénients de conserver le SQL dans les procédures stockées par rapport au code ? qui est également un wiki communautaire.