Pourquoi ne pas utiliser une table au lieu d'une vue matérialisée?
Je suis nouveau dans les bases de données Oracle. Si j'ai bien compris, la vue matérialisée est une vue dont l'ensemble de résultats est enregistré en tant que table physique dans la base de données et cette vue/table est actualisée sur la base d'un paramètre. Si la vue est enregistrée en tant que table physique, pourquoi ne pas stocker les données dans une table en premier lieu? Quel est donc l'avantage d'utiliser une vue matérialisée au lieu d'une table?
L'un des principaux avantages de l'utilisation d'une vue matérialisée est qu'Oracle prend soin de maintenir la synchronisation des données. Si vous disposez d'une table d'agrégation distincte, vous êtes responsable de la synchronisation des données. Cela nécessite généralement une quantité raisonnable de code et une quantité décente de tests et la plupart des organisations parviennent à faire des erreurs qui laissent des trous qui empêchent la table agrégée de se synchroniser. Cela est particulièrement vrai lorsque vous essayez d'implémenter des actualisations incrémentielles de la table d'agrégation.
Un autre avantage majeur est que, selon les paramètres, Oracle peut utiliser la réécriture de requêtes pour utiliser des vues matérialisées lorsque les utilisateurs émettent des requêtes sur des tables de base. Ainsi, par exemple, si vous disposez d'un tas de rapports existants par rapport à une table de détail qui produisent des résultats agrégés quotidiens, mensuels et annuels, vous pouvez créer une vue matérialisée sur la table de base qui agrège les données au niveau quotidien et l'optimiseur peut utilisez cette vue matérialisée pour toutes vos requêtes existantes. Cela rend beaucoup plus facile l'optimisation des charges de travail de génération de rapports dans un entrepôt de données sans essayer d'aller réécrire des dizaines de rapports pour utiliser votre nouvelle table d'agrégation ou pour jouer avec DBMS_ADVANCED_REWRITE pour forcer vos propres réécritures des requêtes.
Les vues matérialisées sont automatiquement mises à jour à mesure que leurs tables de base sont mises à jour.
Un bon exemple d'utilisation de MV est que vous souhaitez parfois agréger des données et obtenir ces informations récapitulatives à partir de grandes tables fréquemment et rapidement. Sans vues matérialisées, vous devez désonormaliser certaines de vos tables et gérer les agrégats via du code ou analyser de manière répétée de grands ensembles de lignes. Dans les deux cas, ce n'est pas toujours acceptable, en particulier avec le tableau de bord et les applications en ligne similaires. Si vous conservez les résultats dans des tableaux séparés, vous compliquez le code de votre application et, comme le dit @Justin Cave, vous serez en charge de vous assurer que les données agrégées manuellement sont synchronisées. avec les données de la table d'origine.
Pas une personne Oracle, mais un autre cas d'utilisation serait des solutions tierces. Ils ne vous aident généralement pas à apporter des modifications à leurs conceptions, mais un MV serait "invisible" pour leur code, mais donnerait accès à des rapports/extraits de données personnalisés.
Ce n'est pas gratuit car cela coûtera des coûts de stockage et des coûts de temps d'insertion/mise à jour potentiellement impactants, mais cela peut être compensé par le temps passé à récupérer les données matérialisées par rapport à une "vue directe" ou à créer des tables réelles et à maintenir l'ETL environnant.
Enfin, cela pourrait annuler votre contrat d'assistance avec le fournisseur, consultez votre avocat-bla-bla-bla
Au lieu d'aller directement à Vues matérialisées laissez-moi vous expliquer Vues.
Fondamentalement, les vues sont logiquement différentes des tables. Si nous voulons cacher certaines colonnes aux utilisateurs, nous ne pouvons pas le faire en utilisant des tableaux. En créant une vue, nous pouvons atteindre la sécurité.
se-case: si une vue est liée en interne avec 10 tables avec group by et que les fonctions ont des millions de lignes, son exécution prend beaucoup de temps.
Voici donc les vues matérialisées qui nous aident à obtenir des données plus rapidement. Les vues matérialisées existent physiquement dans la base de données. Chaque fois que la table de base est mise à jour, la vue matérialisée est mise à jour.
Les vues matérialisées sont mises à jour périodiquement en fonction de la définition de la requête, la table ne peut pas le faire.
Une vue matérialisée est un objet de base de données qui contient les résultats d'une requête. Ce sont des copies locales de données situées à distance ou sont utilisées pour créer des tableaux récapitulatifs basés sur des agrégations de données d'un tableau. http://www.oraappdata.com/2016/04/materialized-view.html
Une vue matérialisée peut être configurée pour se rafraîchir automatiquement sur une base périodique. Une table peut avoir besoin de code supplémentaire pour tronquer/recharger les données.
exemple: une vue matérialisée contenant des données de plusieurs tables peut être configurée pour s'actualiser automatiquement pendant les heures creuses. Une table physique aurait besoin d'un code supplémentaire pour tronquer/recharger les données.
La sécurité peut être mieux contrôlée dans une vue matérialisée plutôt que dans une table.