Quand utiliser une vue au lieu d'un tableau?

108

Quand une vue doit-elle être utilisée sur une table réelle? Quels gains dois-je espérer que cela produira?

Dans l'ensemble, quels sont les avantages d'utiliser une vue sur une table? Ne devrais-je pas concevoir le tableau de la manière dont la vue devrait ressembler en premier lieu?

sql database-design view

— bevacqua
source

80

Oh, il y a de nombreuses différences que vous devrez considérer

Vues pour la sélection:

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

Vues pour insertion / mises à jour:

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

Désavantages

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

— Lukas Eder
source

3

Question rapide: les vues sont-elles «permanentes» ou ne durent-elles que la vie de la session? Raison pour laquelle je pose la question: nous avons un système qui tombe parfois en panne au milieu d'une longue exécution de code. J'atténue cela en mordant des parties du code dans des tables intermédiaires qui enregistrent des résultats intermédiaires. Donc, si le système échoue avant que le code ne soit terminé, je n'ai qu'à reprendre à partir de la dernière table temporaire enregistrée. Je pourrais passer à l'utilisation des vues si elles offrent la même permanence. Sinon, je continuerai de faire la même chose et je baisserai les températures à la fin de la course. THX!

— ouonomos

8

@ouonomos: une vue normale ne contient aucune donnée. Il s'agit simplement d'une instruction SQL stockée, c'est-à-dire d'une vue sur les données sous-jacentes. Certaines bases de données (par exemple Oracle, PostgreSQL) supportent les vues matérialisées, qui stockent temporairement la "vue" dans une autre table pour un accès plus rapide. Ceci est fait pour accélérer l'accès en lecture lorsque la vue est complexe. Mais cela ne vous aide pas dans votre cas, car une vue matérialisée est toujours une vue, pas des données en soi. Votre approche est probablement correcte.

— Lukas Eder

44

Les vues peuvent:

Simplifier une structure de table complexe
Simplifiez 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 permet de changer 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 (vues indexées du serveur SQL)
Offrez une optimisation de requête spécifique avec une vue qui pourrait être difficile à glaner autrement

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

De plus, demander "quels sont les avantages d'utiliser une vue sur une table?" N'est pas une bonne comparaison. Vous ne pouvez pas vous passer de tables, mais vous pouvez vous passer de vues. Ils existent chacun pour une raison très différente. Les tableaux sont le modèle concret et les vues sont une vue abstraite.

— Paul Sasik
source

1

Les vues +1 sont en partie un outil qui atténue les complexités liées à un modèle normalisé efficace en vous permettant d'abstraire cette complexité.

— metdos

34

Les vues sont acceptables lorsque vous devez vous assurer qu'une logique complexe est suivie à chaque fois. Par exemple, nous avons une vue qui crée les données brutes nécessaires à 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, plutôt que d'un rapport utilisant un ensemble de jointures et un autre en oubliant d'en utiliser un 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 les enregistrements mais que vous marquez uniquement l'actuel comme actif et les anciennes versions comme inactives, vous souhaitez qu'une vue soit utilisée pour sélectionner uniquement les enregistrements actifs. Cela évite aux utilisateurs d'oublier de placer la clause where dans la requête et d'obtenir de mauvais résultats.

Les vues peuvent être utilisées pour garantir 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 peut signifier que les utilisateurs de ce client ne peuvent voir que les données pour ce client.

Les vues sont très utiles lors de la refactorisation 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 (au moins dans SQL Server). Nous avons presque perdu un client de plusieurs millions de dollars parce que quelqu'un a choisi de résumer la base de données de cette façon et les performances étaient horribles et les délais d'attente fréquents. Nous avons dû payer pour le correctif également, pas pour le client, car le problème de performances était entièrement de notre faute. Lorsque les vues appellent des vues, elles doivent générer complètement la vue sous-jacente. J'ai vu cela là où la vue appelait une vue qui appelait une vue et tant de millions d'enregistrements ont été générés afin de voir les trois dont l'utilisateur avait finalement besoin. Je me souviens que l'une de ces vues a pris 8 minutes pour faire un simple décompte (*) des enregistrements. Les vues appelant des vues sont une très mauvaise idée.

Les vues sont souvent une mauvaise idée à utiliser pour mettre à jour les enregistrements car vous ne pouvez généralement 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 tel est le cas, il est plus judicieux de mettre à jour directement les tables de toute façon afin que vous sachiez quels champs sont disponibles.

— HLGEM
source

1

Je ne savais pas qu'il y avait un problème de performances avec la vue appelant. Cela semble étrange. N'est-ce pas correctement géré par l'optimiseur de requêtes? Quelle version de SQL Server a été utilisée dans votre cas?

— Patrick Honorez

7

Les vues sont pratiques lorsque vous devez sélectionner parmi plusieurs tables, ou simplement pour obtenir un sous-ensemble d'une table.

Vous devez concevoir vos tables de manière à ce que votre base de données soit bien normalisée (duplication minimale). Cela peut rendre les requêtes quelque peu difficiles.

Les vues sont un peu séparées, vous permettant d' afficher les données des tables différemment de celles stockées.

— Oded
source

7

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 la performance (en cas de vues matérialisées)

— TToni
source

6

Vous devez concevoir votre table SANS tenir compte des vues.
Outre l'enregistrement des jointures et des conditions, les vues présentent un avantage en termes de performances: SQL Server peut calculer et enregistrer son plan d'exécution dans la vue, et donc le rendre plus rapide que les instructions SQL «à la volée».
View peut également faciliter votre travail concernant l'accès des utilisateurs au niveau du terrain.

— Patrick Honorez
source

5

Tout d'abord, comme son nom l'indique, une vue est immuable. c'est parce qu'une vue n'est rien d'autre qu'une table virtuelle créée à partir d'une requête stockée dans la base de données. Pour cette raison, vous avez certaines caractéristiques des vues:

vous ne pouvez afficher qu'un sous-ensemble des données
vous pouvez joindre plusieurs tables en une seule vue
vous pouvez agréger des données dans une vue (sélectionnez le nombre)
view ne contient pas réellement de données, ils n'ont besoin d'aucun tablespace car ce sont des agrégations virtuelles de tables sous-jacentes

il existe donc des milliards de cas d'utilisation pour lesquels les vues sont mieux adaptées que les tableaux, pensez simplement à n'afficher que les utilisateurs actifs sur un site Web. une vue serait meilleure car vous n'opérez que sur un sous-ensemble des données qui se trouvent réellement dans votre base de données (utilisateurs actifs et inactifs)

consultez cet article

j'espère que cela a aidé.

— fasseg
source

2

Selon Wikipedia ,

Les vues peuvent offrir de nombreux avantages par rapport aux tableaux:

Les vues peuvent représenter un sous-ensemble des données contenues dans une table.
Les vues peuvent limiter le degré d'exposition des tables sous-jacentes au monde extérieur: un utilisateur donné peut avoir l'autorisation d'interroger la vue, tout en refusant l'accès au reste de la table de base.
Les vues peuvent joindre et simplifier plusieurs tables en une seule table virtuelle.
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.
Les vues peuvent masquer la complexité des données. Par exemple, une vue peut apparaître sous la forme Sales2000 ou Sales2001, partitionnant de manière transparente la table sous-jacente réelle.
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.
Les vues peuvent fournir une sécurité supplémentaire , selon le moteur SQL utilisé.

— Loukan ElKadi
source