Quelle est une bonne raison d'utiliser les vues SQL?

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?

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:

1. Les vues peuvent représenter un sous-ensemble des données contenues dans une table
2. Les vues peuvent joindre et simplifier plusieurs tables en une seule table virtuelle
3. Les vues peuvent agir comme des tables agrégées , où le moteur de base de données agrège les données (somme, moyenne, etc.) et présente les résultats calculés dans le cadre des données
4. Les vues peuvent masquer la complexité des données ; par exemple, une vue peut apparaître comme Sales2000 ou Sales2001, partitionnant de manière transparente la table sous-jacente
5. Les vues prennent très peu de place à stocker ; la base de données contient uniquement la définition d'une vue, pas une copie de toutes les données qu'elle présente
6. Selon le moteur SQL utilisé, les vues peuvent fournir une sécurité supplémentaire
7. Les vues peuvent limiter le degré d'exposition d'une ou de plusieurs tables au monde extérieur

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

• Simplicité - Les vues peuvent être utilisées pour masquer des requêtes complexes.
• Sécurité - View peut masquer certaines informations importantes de l'utilisateur final en créant une vue sur certaines colonnes sélectionnées
• Sécurité - Table sécurisée pour modifier sa structure à l'aide de VIEW.
• Redondance - Réduisez le code redondant dans chaque procédure / requête en utilisant une vue commune.
• Calcul - Tous les calculs peuvent être effectués une fois dans la requête de vue.
• Nom significatif - La table peut avoir un nom pour id comme tbl_org_emp_id qui peut avoir un alias comme [Employee No] ou un nom significatif.

de imexploring.com

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.