Je lis la Bible de SQL Server 2008 et je couvre la section des vues. Mais l'auteur n'explique pas vraiment le but des vues. Qu'est-ce qu'une bonne utilisation des vues? Dois-je les utiliser sur mon site Web et quels en sont les avantages?
Réponses:
Une autre utilisation qu'aucune des réponses précédentes ne semble avoir mentionnée est le déploiement plus facile des changements de structure de table.
Supposons que vous souhaitiez retirer une table ( T_OLD) contenant des données pour les utilisateurs actifs, et utiliser à la place une nouvelle table avec des données similaires (nommées T_NEW) mais contenant des données pour les utilisateurs actifs et inactifs, avec une colonne supplémentaire active.
Si vos systèmes ont des milliards de requêtes qui le font SELECT whatever FROM T_OLD WHERE whatever, vous avez deux choix pour le déploiement:
1) Cold Turkey - Changez la base de données, et en même temps, changez, testez et publiez de nombreux morceaux de code contenant ladite requête. TRES difficile à faire (ou même à coordonner), très risqué. Mauvais.
2) Graduel - changez le DB en créant la T_NEWtable, en supprimant la T_OLDtable et en créant à la place une VUE appelée T_OLDqui imite la T_OLDtable à 100% (par exemple, la requête de vue est SELECT all_fields_except_active FROM T_NEW WHERE active=1).
Cela vous permettrait d'éviter de publier N'IMPORTE QUEL code qui sélectionne actuellement T_OLDet d'effectuer les modifications pour migrer le code de T_OLDvers T_NEWà votre guise.
Ceci est un exemple simple, il y en a d'autres beaucoup plus impliqués.
PS D'un autre côté, vous auriez probablement dû avoir une API de procédure stockée au lieu de requêtes directes T_OLD, mais ce n'est pas toujours le cas.
(Copié à partir du premier tutoriel qui est apparu dans une recherche Google (lien maintenant mort), mais il présente tous les avantages que j'aurais tapés manuellement moi-même.)
Les vues présentent les avantages suivants:
- Sécurité - Les vues peuvent être rendues accessibles aux utilisateurs tandis que les tables sous-jacentes ne sont pas directement accessibles. Cela permet au DBA de fournir aux utilisateurs uniquement les données dont ils ont besoin, tout en protégeant les autres données de la même table.
- Simplicité - Les vues peuvent être utilisées pour masquer et réutiliser des requêtes complexes.
- Simplification ou clarification du nom de colonne - Les vues peuvent être utilisées pour fournir des alias sur les noms de colonne afin de les rendre plus mémorables et / ou significatifs.
- Tremplin - Les vues peuvent fournir un tremplin dans une requête «à plusieurs niveaux». Par exemple, vous pouvez créer une vue d'une requête qui compte le nombre de ventes effectuées par chaque vendeur. Vous pouvez ensuite interroger cette vue pour regrouper les commerciaux en fonction du nombre de ventes qu'ils ont réalisées.
Quelques raisons de Wikipédia :
Les vues peuvent offrir des avantages par rapport aux tableaux:
VIEWS peut être utilisé comme des sections réutilisables de SELECT / CODE, qui peuvent être incluses dans d'autres sélections / requêtes à joindre, et utiliser différents filtres différents, sans avoir à recréer le SELECT entier à chaque fois.
Cela place également la logique dans un emplacement unique, de sorte que vous n'ayez pas à la modifier dans toute la base de code.
Jettes un coup d'oeil à
Choix entre procédures stockées, fonctions, vues, déclencheurs, SQL en ligne
La principale beauté d'une vue est qu'elle peut être utilisée comme une table dans la plupart des situations, mais contrairement à une table, elle peut encapsuler des calculs très complexes et des jointures couramment utilisées. Il peut également utiliser à peu près n'importe quel objet de la base de données, à l'exception des procédures stockées. Les vues sont plus utiles lorsque vous devez toujours joindre le même ensemble de tables, par exemple une commande avec un détail de commande pour obtenir des champs de calcul récapitulatif, etc.
Une vue est une couche d'abstraction, et elle fait ce que fait toute bonne couche d'abstraction, y compris encapsuler le schéma de base de données et vous protéger des conséquences de la modification des détails d'implémentation internes.
C'est une interface.
Voici une utilisation très courante de l'utilisation de vues pour contraindre une entité par certains critères.
Tableau: USERS contient tous les utilisateurs
Affichage: ACTIVE_USERS contient tous les utilisateurs à l'exception de ceux qui sont suspendus, bannis, en attente d'activation et ne répondant à aucun des critères que vous pourrez choisir de définir à l'avenir dans le cadre des exigences actives. Cela rend inutile la suppression de lignes de votre table USERS si vous choisissez de ne pas le faire, car ACTIVE_USERS peut toujours masquer les lignes indésirables.
De cette façon, vous pouvez utiliser la table dans vos pages de gestion des utilisateurs, mais le reste de l'application peut utiliser ACTIVE_USERS car ils peuvent être les seuls utilisateurs qui devraient pouvoir exécuter des processus et accéder / modifier des données.
Les vues peuvent vous permettre de combiner des données de plusieurs tables différentes et de les formater (combiner des champs, donner des noms de champs plus significatifs, etc.) afin que ce soit plus facile pour les utilisateurs finaux. Ils sont une abstraction du modèle de base de données. Ils peuvent également être utilisés pour donner aux utilisateurs l'accès aux données de la table sans leur donner un accès direct à la table elle-même.
Voici quelques-unes des nombreuses raisons d'utiliser la vue plutôt que la table directement
Une petite liste de raisons / utilisations courantes:
utilisez-les pour changer le format ou l'apparence des données (c'est-à-dire que vous pouvez joindre un prénom et un nom ensemble)
effectuer des calculs ou d'autres recherches sur les données
dénormaliser les données (extraire les données de plusieurs tables en un seul endroit)
Les vues sont mauvaises! Évitez-les si possible et utilisez uniquement pour la raison mentionnée par DVK - la migration temporaire des données.
Vous devez comprendre que dans une base de données avec 100 tables, il est difficile de se souvenir de l'objectif de chaque table. Maintenant, si vous ajoutez ici 300 autres vues, cela deviendra un désordre complet. Ensuite, les «amateurs de vues» ont tendance à utiliser des vues imbriquées, puis à utiliser les vues imbriquées dans les procédures stockées. Je travaille personnellement maintenant avec une base de données où il y a des vues imbriquées en profondeur 4 fois! Donc, pour comprendre la logique la plus simple d'une procédure stockée, je dois d'abord parcourir toutes les vues.