Quand utiliser une vue au lieu d'un tableau ?

Question

Quand faut-il utiliser une vue plutôt qu'un tableau réel ? Quels sont les avantages que je dois en attendre ?

Globalement, quels sont les avantages d'utiliser une vue plutôt qu'une table ? Ne devrais-je pas concevoir le tableau de la manière dont la vue devrait ressembler en premier lieu ?

Answer 1

Oh, il y a beaucoup de différences que vous devrez prendre en compte

Vues pour la sélection :

1. Les vues fournissent une abstraction par rapport aux tables. Vous pouvez facilement ajouter/supprimer des champs dans une vue sans modifier votre schéma sous-jacent.
2. Les vues peuvent facilement modéliser des jointures complexes.
3. Les vues peuvent vous cacher des éléments spécifiques à la base de données. Par exemple, si vous devez effectuer des vérifications en utilisant la fonction SYS_CONTEXT d'Oracles ou bien d'autres choses encore
4. Vous pouvez facilement gérer vos subventions directement sur les vues, plutôt que sur les tables réelles. C'est plus facile à gérer si vous savez qu'un certain utilisateur ne peut accéder qu'à une vue.
5. Les vues peuvent vous aider à assurer la rétrocompatibilité. Vous pouvez modifier le schéma sous-jacent, mais les vues peuvent cacher ces faits à un certain client.

Vues pour l'insertion/mise à jour :

1. Vous pouvez gérer les problèmes de sécurité avec les vues en utilisant une fonctionnalité telle que la clause "WITH CHECK OPTION" d'Oracle directement dans la vue.

Inconvénients

1. Vous perdez des informations sur les relations (clés primaires, clés étrangères).
2. Il n'est pas évident de savoir si vous pourrez insérer/mettre à jour une vue, parce que la vue vous cache ses jointures sous-jacentes.

Answer 2

Les vues peuvent :

• Simplifier une structure de tableau complexe
• Simplifier votre modèle de sécurité en vous permettant de filtrer les données sensibles et d'attribuer des autorisations de manière plus simple.
• vous permettent de modifier la logique et le comportement sans changer la structure de sortie (la sortie reste la même mais le SELECT sous-jacent pourrait changer de manière significative)
• Augmenter les performances (Sql Server Indexed Views)
• Offrir une optimisation spécifique des requêtes avec la vue qui pourrait être difficile à glaner autrement.

Et vous ne devez pas concevoir des tables pour correspondre à des vues . Votre modèle de base devrait se préoccuper de l'efficacité du stockage et de la récupération des données. Les vues sont en partie un outil qui atténue les complexités qui découlent d'un modèle efficace et normalisé en vous permettant d'abstraire cette complexité.

De même, demander " quels sont les avantages d'utiliser une vue plutôt qu'une table ? "n'est pas une bonne comparaison. Vous ne pouvez pas vous passer des tables, mais vous pouvez vous passer des vues. Elles existent toutes deux pour une raison très différente. Les tableaux sont le modèle concret et les vues sont un modèle abstrait, eh bien, une vue.

Answer 3

Les vues sont acceptables lorsque vous devez vous assurer que la logique complexe est respectée à chaque fois. Par exemple, nous avons une vue qui crée les données brutes nécessaires pour tous les rapports financiers. En faisant en sorte que tous les rapports utilisent cette vue, tout le monde travaille à partir du même ensemble de données, au lieu qu'un rapport utilise un ensemble de jointures et qu'un autre oublie d'en utiliser un, ce qui donne des résultats différents.

Les vues sont acceptables lorsque vous souhaitez restreindre les utilisateurs à un sous-ensemble particulier de données. Par exemple, si vous ne supprimez pas d'enregistrements mais que vous marquez seulement les enregistrements actuels comme actifs et les anciennes versions comme inactives, vous voulez une vue à utiliser pour sélectionner uniquement les enregistrements actifs. Cela permet d'éviter que les utilisateurs oublient de mettre la clause where dans la requête et obtiennent de mauvais résultats.

Les vues peuvent être utilisées pour s'assurer que les utilisateurs n'ont accès qu'à un ensemble d'enregistrements - par exemple, une vue des tables pour un client particulier et aucun droit de sécurité sur les tables peuvent signifier que les utilisateurs de ce client ne peuvent jamais voir que les données de ce client.

Les vues sont très utiles lors du remaniement des bases de données.

Les vues ne sont pas acceptables lorsque vous utilisez des vues pour appeler des vues, ce qui peut entraîner des performances horribles (du moins dans SQL Server). Nous avons presque perdu un client de plusieurs millions de dollars parce que quelqu'un a choisi d'abstraire la base de données de cette façon et que les performances étaient épouvantables et les dépassements de temps fréquents. C'est nous qui avons dû payer pour la réparation, et non le client, car le problème de performances était entièrement de notre faute. Lorsque des vues appellent des vues, elles doivent générer complètement la vue sous-jacente. J'ai vu cela où la vue appelait une vue qui appelait une vue et plusieurs millions d'enregistrements étaient générés afin de voir les trois dont l'utilisateur avait finalement besoin. Je me souviens qu'une de ces vues a pris 8 minutes pour faire un simple comptage (*) des enregistrements. Les vues qui appellent des vues sont une idée extrêmement mauvaise.

Les vues sont souvent une mauvaise idée pour la mise à jour des enregistrements car, en général, vous ne pouvez mettre à jour que les champs de la même table (encore une fois, il s'agit de SQL Server ; les autres bases de données peuvent varier). Si c'est le cas, il est plus logique de mettre à jour directement les tables de toute façon, afin de savoir quels champs sont disponibles.

Answer 4

Une pratique courante consiste à masquer les jointures dans une vue pour présenter à l'utilisateur un modèle de données plus dénormalisé. D'autres utilisations concernent la sécurité (par exemple en masquant certaines colonnes et/ou lignes) ou les performances (dans le cas des vues matérialisées).

Answer 5

Vous devez concevoir votre tableau SANS tenir compte des vues.
En plus d'économiser les jointures et les conditions, les vues présentent un avantage en termes de performances : SQL Server peut calculer et sauvegarder son plan d'exécution dans la vue, et donc la rendre plus rapide que les instructions SQL "à la volée".
View peut également faciliter votre travail concernant l'accès des utilisateurs sur le terrain.