À quoi servent les vues?

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) À 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 ¹ 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 ¹ 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;)

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.

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.

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.

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.

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.

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.

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.

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).

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.

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

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).

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.

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.