Je sais que dans SQL Server, vous pouvez créer des index sur une vue, puis la vue enregistre les données de la table sous-jacente. Ensuite, vous pouvez interroger la vue. Mais, pourquoi ai-je besoin d'utiliser la vue au lieu de la table?Dans SQL Server, quand dois-je utiliser une vue indexée au lieu d'une table réelle?
Vous pouvez utiliser une vue pour simplifier les requêtes. Dans nos projets, le consensus est sur l'utilisation des vues pour les interfaces, et en particulier les "interfaces de rapport". Imaginez que vous ayez une table client et que le responsable souhaite un rapport tous les matins avec le nom du client et le solde de son compte (ou autre). Si vous codez votre rapport par rapport à la table, vous créez un lien fort entre votre rapport et votre table, ce qui complique les modifications ultérieures. D'autre part, si votre rapport atteint une vue, vous pouvez tordre la base de données librement; Tant que la vue est la même que le rapport fonctionne, le gestionnaire est content et vous êtes libre d'expérimenter avec la base de données. Vous souhaitez séparer les métadonnées client de la table client principale? allez-y, et joignez les deux tables dans la vue. Vous voulez dénormaliser les informations du panier pour le client? pas de problème, la vue peut adapter ...
Pour être honnête, il est mon avis en tant que programmeur, mais d'autres utilisations sera certainement trouvée par les gourous db :)
Est-ce que votre gestionnaire veut un rapport tous les matins avec le gelé périmé à un moment donné des soldes des clients? S'il veut des données actualisées, il est à nouveau le même, créant le même lien fort entre le rapport et la table, mais via un intermédiaire supplémentaire (vue indexée). Que voulez-vous dire expérimenter avec la base de données. La base de données est-elle un jouet? Expérimentez avec des vues! Je ne pouvais pas voir aucune partie de toute justification valable dans cette logique –
Acutally souvent, il le fait. Les ventes quotidiennes peuvent être définies comme étant des ventes jusqu'au dernier jour - de sorte que tout le monde utilise les mêmes numéros, même si le rapport est publié une heure plus tard. Les entrepôts de données (rapports typiques) sont généralement chargés par intervalles, pas en temps réel. – TomTom
@ TomTom, oui, vous l'avez. De plus, vous pouvez avoir un serveur très actif où des requêtes complexes de l'interface de rapport peuvent tuer les performances réelles. – samy
Fondamentalement, utiliser une vue:
Les vues indexées peuvent améliorer les performances en créant un index plus spécifique sans augmenter la redondance.
Une vue est simplement une instruction SELECT qui a reçu un nom et qui est stockée dans une base de données. L'avantage principal d'une vue est qu'une fois créée, elle agit comme une table pour toutes les autres instructions SELECT que vous voulez écrire.
L'instruction select pour la vue peut référencer des tables, d'autres vues et des fonctions.
Vous pouvez créer un index sur la vue (vue indexée) pour améliorer les performances. Une vue indexée est mise à jour automatiquement, reflétant immédiatement les modifications apportées aux tables sous-jacentes. Si votre vue indexée ne sélectionne que les colonnes d'une table, vous pouvez tout aussi bien placer l'index sur cette table et interroger cette table directement, la vue ne provoquera que des frais supplémentaires pour votre base de données. Cependant, si votre instruction SELECT couvre plusieurs tables avec des jointures, etc., vous pourriez obtenir un gain de performance en plaçant un index sur la vue.
Si je peux qoute le démarreur de sujet: "Mais, pourquoi j'ai besoin d'utiliser la vue au lieu de table?" –
Une table est l'endroit où les données sont stockées physiquement.
Une vue est l'endroit où les tables sont résumées ou groupées pour faciliter l'utilisation des groupes de tables. Une vue indexée permet à une requête d'utiliser une vue et non pas d'obtenir des données de la table sous-jacente, car la vue contient déjà les données, ce qui augmente les performances.
Vous ne pouviez pas obtenir le même résultat avec seulement des tables, sans dénormaliser votre base de données et ainsi potentiellement créer d'autres problèmes.
Quel est le sens dans "Vous ne pourriez pas obtenir les mêmes résultats avec juste des tables"? Extraction de certaines données, en les isolant de la base de données. La prochaine étape consiste simplement à laisser tomber la base de données pour finalement augmenter les performances. Désolé, je ne vois aucune logique valable sous cette logique. –
Un avantage de l'utilisation d'une vue indexée est de classer les résultats de 2 colonnes ou plus, où les colonnes se trouvent dans des tables différentes. c'est-à-dire, avoir une vue qui est le résultat de table1 et table2 triés par table1.column1, table2.column2. Vous pouvez alors créer un index sur column1, column2 pour optimiser cette requête
Puisque les vues peuvent rejoindre des tables gigantesques et appliquer un tri sur des colonnes non indexées, est-il utile d'ajouter des index aux tables d'origine, au lieu de la vue? J'ai lu qu'une vue indexée peut augmenter la contention avec les tables sous-jacentes, mais si votre vue est ordonnée par des colonnes spécifiques, pourquoi pas d'autre? –
Ayant lu toutes les réponses, je ne vois toujours pas de raison valable d'utiliser la vue indexée au lieu de la vraie table –
@Yousi, votre réponse acceptée ne dit pas grand chose (ou quoi que ce soit d'autre) sur les vues INDEXÉES. –
Oui, je pense que vous avez raison. –