•  03-07-2019
  •  | 
  •  

Question

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 pour quoi je les ai utilisées dans le passé.

Mais je veux m'assurer de bien comprendre en quoi une vue est utile et à laquelle une vue ne devrait pas être utile. Plus spécifiquement:

  1. À quoi sert une vue?
    • Existe-t-il des situations dans lesquelles il est tentant d'utiliser une vue alors que vous ne devriez pas en utiliser?
    • Pourquoi voudriez-vous utiliser une vue au lieu de quelque chose comme une fonction de valeur table ou vice versa?
    • Existe-t-il des circonstances dans lesquelles une vue pourrait être utile et qui ne sont pas évidentes au premier abord?

(Et pour mémoire, certaines de ces questions sont intentionnellement naïves. Ceci est en partie une vérification de concept.)

Était-ce utile?

La solution

1) A quoi sert une vue?

IOPO À un seul endroit


• Que vous considériez les données elles-mêmes ou les requêtes qui référencent les tables jointes, l'utilisation d'une vue évite les redondances inutiles.

• Les vues fournissent également une couche abstraite empêchant l'accès direct aux tables (et le menottage résultant référençant des dépendances physiques). En fait, je pense que la bonne pratique 1 consiste à n'offrir qu'un accès abstrait à vos données sous-jacentes (à l'aide de vues et de fonctions à valeur table), y compris des vues telles que

CREATE VIEW AS
& nbsp; & nbsp; & nbsp; SELECT * FROM tblData

1 Je dois admettre qu'il y a beaucoup de "Faites ce que je dis; pas comme je le fais " dans ce conseil;)

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

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

Une autre situation dans laquelle une vue peut être surexploitée est celle où la vue est référencée uniquement à partir d'un emplacement d'appel et où une table dérivée peut être utilisée. Tout comme un type anonyme est préférable à une classe dans .NET si le type anonyme est utilisé / référencé une seule fois.

& nbsp; & nbsp; • Voir la description de la table dérivée dans & nbsp; http://msdn.microsoft.com/en-us/library/ms177634.aspx

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

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

4) Y a-t-il des circonstances dans lesquelles une vue pourrait être utile et qui ne sont pas évidentes au premier abord?

Je ne vois aucune utilisation non apparente du haut de ma tête. (Je suppose que si je pouvais, cela les rendrait visibles;)

Autres conseils

En un sens, une vue est comme une interface. Vous pouvez modifier la structure de la table sous-jacente à votre guise, mais la vue permet au code de ne pas avoir à changer.

Les vues sont un bon moyen de fournir quelque chose de simple aux rédacteurs de rapports. Si les utilisateurs de votre entreprise souhaitent accéder aux données à partir de Crystal Reports, vous pouvez leur donner des vues les simplifiant, voire les dénormaliser pour eux.

Les vues peuvent être utilisées pour assurer la sécurité (les utilisateurs peuvent avoir accès à des vues n'accédant qu'à certaines colonnes d'un tableau), les vues pouvant fournir une sécurité supplémentaire aux mises à jour, insertions, etc. Les vues permettent également de créer des noms de colonnes alias. (comme le font les sp), mais les vues sont davantage un isolement de la table réelle.

En 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 de nombreuses applications font de toute façon par le biais de la modélisation de domaine dans leurs objets. Ils aident à présenter les données d’une manière qui correspond mieux au point de vue d’une entreprise.

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

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

Par exemple, au lieu de faire dans une application:

  

sql = " sélectionnez a, b dans l'union table1   sélectionnez a, b dans la table2 " ;;

Vous pouvez résumer cela à une vue:

  

crée la vue union_table1_table2_v en tant que
  sélectionnez un, b dans la table1
  union
  sélectionnez a, b dans la table2

et dans le code de l'application, il vous suffit d'avoir:

  

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

De plus, si les structures de données changent, vous ne devrez pas modifier le code de l'application, recompiler et redéployer. vous voudriez simplement changer la vue dans la base de données.

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

Vous ne souhaitez pas utiliser une vue pour remplacer des jointures complexes. En d'autres termes, ne laissez pas votre habitude de programmation procédurale de décomposer un problème en éléments plus petits vous amène à utiliser plusieurs vues jointes au lieu d'une jointure plus grande. Cela réduirait l'efficacité du moteur de base de données car il effectue essentiellement plusieurs requêtes distinctes au lieu d'une seule plus grande.

Par exemple, supposons que vous deviez joindre les tables A, B, C et D. Vous pouvez être tenté de créer une vue à partir des tableaux A & amp; B et une vue sur C & amp; D, ensuite, associez les deux vues. Il est bien mieux de joindre A, B, C et D en une requête.

Les vues peuvent centraliser ou consolider des données. Là où j'en suis, nous avons un certain nombre de bases de données différentes sur plusieurs 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 relatives à différentes applications. Dans ces circonstances, nous allons 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 traverser différentes bases de données.

Les réponses jusqu’à présent sont correctes - les vues sont bonnes pour la sécurité, la dénormalisation (même s’il est très pénible de se faire mal), l’abstraction du modèle de données, etc.

De plus, les vues sont couramment utilisées pour mettre en œuvre 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 répétées complexes dans vos scripts SQL. Vous pouvez simplement encapsuler une jointure complexe dans une vue et l'appeler dans votre instruction SELECT chaque fois que cela est nécessaire. Cela serait parfois pratique, simple et plus simple que d’écrire les instructions de jointure dans chaque requête.

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

Je voulais souligner l'utilisation des vues pour les rapports. Il existe souvent un conflit entre la normalisation des tables de la base de données pour améliorer les performances, notamment lors de la modification et de l'insertion de données (utilisations OLTP), et la dénormalisation afin de réduire le nombre de jointures de table pour les requêtes de génération de rapports et d'analyse (utilisations OLAP). Par nécessité, OLTP gagne généralement, car la saisie des données doit avoir des performances optimales. La création de vues, pour des performances optimales en matière de création de rapports, peut donc 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 UNIONs. Chaque UNION incluait une pièce jointe à une table de prix créée à 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 qui crée le tableau des prix. Le SELECT global aurait été raccourci d'environ la moitié.

Je ne sais pas si la base de données évalue la vue une fois ou une fois à chaque fois dans. Quelqu'un sait? Si le premier cas, utiliser une vue améliorerait les performances.

Chaque fois que vous avez besoin de [mon_interface]! = [utilisateur_interface].

Exemple:

TABLEAU A:

  • id
  • info

VIEW for TABLE A:

  • Informations client

C’est une façon de cacher l’id du client et de renommer l’information 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 performance, mais une meilleure abstraction de la requête de sélection.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top