À quoi servent les vues?


87

J'essaie simplement d'avoir une idée générale de l'utilisation des vues dans les SGBDR. C'est-à-dire que je sais ce qu'est une vue et comment en faire une. Je sais aussi pourquoi je les ai utilisés dans le passé.

Mais je veux m'assurer de bien comprendre à quoi sert une vue et à quoi une vue ne devrait pas l'être. Plus précisement:

  1. À quoi sert une vue?
    • Y a-t-il des situations dans lesquelles il est tentant d'utiliser une vue alors que vous ne devriez pas en utiliser une?
    • Pourquoi utiliseriez-vous une vue au lieu de quelque chose comme une fonction table ou vice versa?
    • Y a-t-il des circonstances dans lesquelles une vue pourrait être utile qui ne sont pas apparentes à première vue?

(Et pour mémoire, certaines de ces questions sont intentionnellement naïves. Il s'agit en partie d'une vérification conceptuelle.)


1
similaire à la question posée ici: stackoverflow.com/questions/1278521/…
MedicineMan

Je pense que stackoverflow.com/questions/1278521/ ... fournit de meilleures réponses à cette question.
GinTonic

Réponses:


42

1) À quoi sert une vue?

IOPO en un seul endroit

• Que vous preniez en compte les données proprement dites ou les requêtes faisant référence aux tables jointes, l'utilisation d'une vue évite une redondance inutile.

• Les vues fournissent également une couche d'abstraction empêchant l'accès direct aux tables (et les menottes qui en résultent faisant référence aux dépendances physiques). En fait, je pense que c'est une bonne pratique 1 de n'offrir qu'un accès abstrait à vos données sous-jacentes (en utilisant des vues et des fonctions de table), y compris des vues telles que 1 Je dois admettre qu'il y a beaucoup de "Faites ce que je dis; pas comme je faire "dans ce conseil;)

CREATE VIEW AS
      SELECT * FROM tblData


2) Y a-t-il des situations dans lesquelles il est tentant d'utiliser une vue alors que vous ne devriez pas en utiliser une?

Les performances des jointures de vue étaient auparavant un problème (par exemple, SQL 2000). Je ne suis pas un expert, mais je ne m'en suis pas inquiété depuis un moment. (Je ne peux pas non plus penser à l'endroit où j'utilise actuellement des jointures de vues.)

Une autre situation où une vue peut être excessive est lorsque la vue n'est référencée qu'à partir d'un emplacement appelant et qu'une table dérivée peut être utilisée à la place. Tout comme un type anonyme est préférable à une classe dans .NET si le type anonyme n'est utilisé / référencé qu'une seule fois.

    • Consultez la description de la table dérivée sur http://msdn.microsoft.com/en-us/library/ms177634.aspx

3) Pourquoi utiliseriez-vous une vue au lieu de quelque chose comme une fonction table ou vice versa?

(Mis à part des raisons de performances) Une fonction table est fonctionnellement équivalente à une vue paramétrée. En fait, un cas d'utilisation courant d'une fonction table simple consiste simplement à ajouter un filtre de clause WHERE à une vue déjà existante dans un seul objet.

4) Y a-t-il des circonstances dans lesquelles une vue pourrait être utile qui ne sont pas apparentes à première vue?

Je ne peux penser à aucune utilisation non apparente du sommet de ma tête. (Je suppose que si je pouvais, cela les rendrait apparents;)

9
Je ne suis pas d'accord pour dire qu'il est logique de créer une vue sur une table lorsqu'il s'agit d'un SELECT * FROM tblData. Pouvez-vous expliquer pourquoi cela serait bénéfique?
Utilisateur enregistré le

IOPO - In One Place Only - Est-ce une expression de conception bien connue? Je n'arrive pas à trouver beaucoup de références? At-il d'autres formes, par exemple DRY?
Robert

1
@Robert Oui, DRY, normalisation, IOPO, ce sont toutes des saveurs différentes de la même philosophie.
TylerH

45

D'une certaine manière, une vue est comme une interface. Vous pouvez modifier la structure de la table sous-jacente autant que vous le souhaitez, mais la vue permet au code de ne pas avoir à changer.

Les vues sont un bon moyen de fournir quelque chose de simple à signaler aux rédacteurs. Si les utilisateurs de votre entreprise souhaitent accéder aux données à partir de quelque chose comme Crystal Reports, vous pouvez leur donner des vues dans leur compte qui simplifient les données - peut-être même les dénormalisent pour eux.


21

Les vues peuvent être utilisées pour assurer la sécurité (c'est-à-dire: les utilisateurs peuvent avoir accès à des vues qui n'accèdent qu'à certaines colonnes d'une table), les vues peuvent fournir une sécurité supplémentaire pour les mises à jour, les insertions, etc. Les vues permettent également d'aliaser les noms de colonnes (comme le font sp's) mais les vues sont plus isolées de la table réelle.


18

Dans un sens, les vues se dénormalisent. La dénormalisation est parfois nécessaire pour fournir des données de manière plus significative. C'est ce que font de toute façon de nombreuses applications via la modélisation de domaine dans leurs objets. Ils aident à présenter les données d'une manière qui correspond plus étroitement à la perspective d'une entreprise.


-1 "vues dénormaliser"? désolé, mais c'est insensé à moins qu'il ne soit qualifié d'une manière ou d'une autre.
juste quelqu'un

18
Ils dénormalisent absolument. Si vous avez des tables liées qui sont normalisées à la 3ème forme nomrale et que vous créez une vue pour «aplatir» cette relation, en quoi n'est-ce pas une dénormalisation?
Kilhoffer

11

En plus de ce que les autres ont déclaré, les vues peuvent également être utiles pour supprimer les requêtes SQL plus compliquées de l'application.

Par exemple, au lieu de faire dans une application:

sql = "sélectionner a, b à partir de la table1 union sélectionner a, b à partir de la table2";

Vous pouvez résumer cela à une vue:

créer la vue union_table1_table2_v comme
select a, b from table1
union
select a, b from table2

et dans le code de l'application, ayez simplement:

sql = "sélectionnez a, b dans union_table1_table2_v";

De plus, si les structures de données changent, vous n'aurez pas à modifier le code de l'application, à recompiler et à redéployer. vous changeriez simplement la vue dans la base de données.


Pourquoi voudrais-je écrire un SQL complexe dans une base de données au lieu d'une application?
Ivan Virabyan

3
Plus votre requête est compliquée, plus elle changera probablement dans le futur, en partie parce qu'elle atteindra simplement plus de tables. Lorsque les structures de base de données changent, vous devrez également modifier votre code et effectuer une version. Si cette complexité est abstraite dans une vue, le DBA peut être en mesure d'apporter des modifications structurelles aux tables sous-jacentes sans que votre code ait à changer.
CodingWithSpike

11

Les vues masquent la complexité de la base de données. Ils sont parfaits pour de nombreuses raisons et sont utiles dans de nombreuses situations, mais si vous avez des utilisateurs qui sont autorisés à écrire leurs propres requêtes et rapports, vous pouvez les utiliser comme garantie pour vous assurer qu'ils ne soumettent pas mal conçus requêtes avec des jointures cartésiennes désagréables qui détruisent votre serveur de base de données.


6

Le PO a demandé s'il y avait des situations où il pourrait être tentant d'utiliser une vue, mais ce n'est pas approprié.

Vous ne souhaitez pas utiliser une vue pour remplacer les jointures complexes. Autrement dit, ne laissez pas votre habitude de programmation procédurale de décomposer un problème en plus petits morceaux vous conduire à utiliser plusieurs vues jointes au lieu d'une plus grande jointure. Cela va tuer l'efficacité du moteur de base de données car il effectue essentiellement plusieurs requêtes distinctes plutôt qu'une plus grande.

Par exemple, disons que vous devez joindre les tables A, B, C et D ensemble. Vous pourriez être tenté de créer une vue à partir des tableaux A et B et une vue à partir de C et D, puis de joindre les deux vues ensemble. Il est préférable de joindre A, B, C et D en une seule requête.


Je ne pense pas que ce soit vrai, du moins ce n'est pas ainsi que se déroule la théorie du SGBD (diverses implémentations peuvent décider de ne pas honorer la théorie). L'analyseur de requête remplacera essentiellement toutes les vues qu'il voit par le sql correspondant, et l'optimiseur partira de là. Les 2 cas doivent être équivalents.
SquareCog

Cela ne vaut pas non plus lorsque vous pouvez ajouter des index à vos vues.
therealhoff

Je suis plus familier avec PostgreSQL et les versions antérieures n'étaient pas très douées pour combiner des requêtes. Mais les plus récents sont bien meilleurs. Ma réponse ne s'applique plus tellement, du moins pour ce SGBD particulier.
Barry Brown

5

Les vues peuvent centraliser ou consolider les données. Là où je suis, nous avons un certain nombre de bases de données différentes sur quelques serveurs liés différents. Chaque base de données contient des données pour une application différente. Quelques-unes de ces bases de données contiennent des informations pertinentes pour un certain nombre d'applications différentes. Ce que nous allons faire dans ces circonstances, c'est créer une vue dans la base de données de cette application qui extrait simplement les données de la base de données où les données sont réellement stockées, de sorte que les requêtes que nous écrivons ne semblent pas aller dans différentes bases de données.


4

Jusqu'à présent, les réponses sont correctes - les vues sont bonnes pour assurer la sécurité, la dénormalisation (bien qu'il y ait beaucoup de douleur sur cette route si elle est mal faite), l'abstraction du modèle de données, etc.

De plus, les vues sont couramment utilisées pour implémenter la logique métier (un utilisateur périmé est un utilisateur qui ne s'est pas connecté au cours des 40 derniers jours, ce genre de chose).


si vous dénormalisez en incorporant 7 tables de référence, puis recherchez quelque chose qui n'a besoin que d'une de ces tables de référence. C'est beaucoup d'efforts inutiles. Cela s'aggrave si vous commencez à rejoindre de telles vues.
SquareCog

es-tu sûr de ça? MSDN dit «Lorsque SQL Server traite des requêtes qui font référence à des vues par nom, les définitions des vues sont normalement développées jusqu'à ce qu'elles se réfèrent uniquement aux tables de base. Ce processus s'appelle l'expansion de la vue. C'est une forme d'expansion macro. » J'imagine que pendant le processus d'expansion, le moteur serait suffisamment intelligent pour inclure uniquement les tables sous-jacentes (de la vue) qui sont nécessaires à la requête.
Anthony

Anthony, imaginez une requête telle que "select foo_col from (select foo. *, Bar. * From foo join bar on (foo.id = bar.id)". Dans cette requête, la sélection interne est notre vue. Ce n'est pas clairement que la jointure de barre peut être supprimée en toute sécurité (en fait, si la relation n'est pas strictement 1-1, elle ne le peut pas). Cela devient encore plus délicat avec des requêtes plus complexes, et je ne recommanderais pas de compter sur le SGBDR générique pour faire tout le élaguer un humain peut. Peut-être que SQL Server le peut; Je serais choqué si MySQL le faisait. Oracle? Postgres? Comme toujours, lisez le plan de requête en cas de doute.
SquareCog

3

Les vues enregistrent de nombreuses instructions JOIN complexes répétées dans vos scripts SQL. Vous pouvez simplement encapsuler un JOIN complexe dans une vue et l'appeler dans votre instruction SELECT chaque fois que nécessaire. Cela serait parfois pratique, simple et plus facile que d'écrire les instructions de jointure dans chaque requête.


2

Une vue est simplement une instruction SELECT stockée et nommée. Pensez à des vues comme les fonctions de bibliothèque.


Les procédures stockées ne conviendraient-elles pas davantage à cela? Parfois, vous avez besoin de fonctions avec des vues de suppressions et de mises à jour qui ne répondraient pas à ce besoin. Les vues doivent être considérées comme des abstractions ou des moyens de limiter l'utilisateur cible.
HumbleWebDev

1

Je voulais mettre en évidence l'utilisation des vues pour le reporting. Souvent, il existe un conflit entre la normalisation des tables de la base de données pour accélérer les performances, en particulier pour l'édition et l'insertion de données (utilisations OLTP), et la dénormalisation pour réduire le nombre de jointures de table pour les requêtes de reporting et d'analyse (utilisations OLAP). Par nécessité, OLTP gagne généralement, car la saisie de données doit avoir des performances optimales. La création de vues, donc, pour des performances de reporting optimales, peut aider à satisfaire les deux catégories d'utilisateurs (saisie de données et visualiseurs de rapports).


1

Je me souviens d'un très long SELECT qui impliquait plusieurs UNION. Chaque UNION comprenait une jointure à un tableau de prix qui était créé à la volée par un SELECT lui-même assez long et difficile à comprendre. Je pense que cela aurait été une bonne idée d'avoir un point de vue pour créer le tableau des prix. Cela aurait réduit le SELECT global d'environ la moitié.

Je ne sais pas si la base de données évaluerait la vue une fois, ou une fois à chaque fois dans était invoquée. Quelqu'un sait? Dans le premier cas, l'utilisation d'une vue améliorerait les performances.


Oracle CBO pourrait choisir d'évaluer la vue une fois (matérialiser, ils l'appellent) ou fusionner le SQL de la vue dans le reste de l'instruction select et l'exécuter. Il déciderait en fonction du coût estimé le plus bas.
WW.

Si l'instruction select était constante tout au long de la requête et simplement répétée plusieurs fois, une expression de table commune (CTE) pourrait résoudre le problème. Cela s'applique uniquement à SQL Server 2005/2008 car il n'était pas disponible dans SQL Server 2000. Oui, une vue aurait quand même été appelée à plusieurs reprises.
Utilisateur enregistré le

@Utilisateur enregistré: les CTE ne sont pas une spécialité de SQL Server. Ils sont originaires de DB2 et sont également présents dans PostgreSQL (car ils sont utiles et dans la norme ISO SQL). Qu'une vue soit intégrée ou traitée comme une boîte noire est spécifique à l'implémentation, certains SGBDR sont plus intelligents que d'autres.
juste quelqu'un

@just somebody: Mon commentaire était limité à SQL Server 2005/2008 car je n'ai pas d'expérience avec les CTE dans d'autres RBDMS. En outre, le commentaire a été qualifié pour indiquer que cela ne s'applique pas à SQL Server 2000 car les CTE n'étaient pas disponibles dans SQL Server avant 2005.
Utilisateur enregistré

Une autre alternative à une vue aurait été de mettre au préalable le tableau des prix dans un tableau temporaire.
SeaDrive

0

Chaque fois que vous avez besoin de [my_interface]! = [User_interface].

Exemple:

TABLEAU A:

  • id
  • Info

VUE DU TABLEAU A:

  • Informations client

c'est une façon de masquer l'identifiant du client et de renommer les informations en un nom plus détaillé à la fois.

La vue utilisera l'index sous-jacent pour l'ID de clé primaire, vous ne verrez donc pas de perte de performances, juste une meilleure abstraction de la requête de sélection.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.