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 en fonction de certains paramètres. Si view est enregistré en tant que table physique, pourquoi ne pas stocker les données dans une table en premier lieu? Alors, quel est 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 le fait qu'Oracle veille à la synchronisation des données. Si vous avez une table agrégée 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 entreprises parviennent à commettre 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égat.

Un autre avantage majeur est que, selon les paramètres, Oracle peut utiliser la réécriture de requête 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 de plusieurs rapports existants associés à une table détaillée générant des résultats globaux 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 permet à l'optimiseur de: utilisez cette vue matérialisée pour toutes vos requêtes existantes. Il est ainsi beaucoup plus facile d’optimiser les charges de travail de génération de rapports dans un entrepôt de données sans essayer de réécrire des dizaines de rapports pour utiliser votre nouvelle table agrégée ou DBMS_ADVANCED_REWRITEpour 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 cas d'utilisation de MV est que vous souhaitez parfois regrouper des données et obtenir ces informations récapitulatives à partir de tables volumineuses 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. Les deux méthodes ne sont pas toujours acceptables, spécialement avec les tableaux de bord et les applications en ligne similaires. Si vous conservez les résultats dans des tableaux distincts, vous compliquez le code de votre application et, comme @Justin Cave l’a dit, vous devrez 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 supportent généralement pas pour 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 / de 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 à la création de tables réelles et au maintien de l'ETL environnant.

Enfin, cela pourrait annuler votre contrat d'assistance avec le fournisseur. Consultez votre avocat, blah, blah, blah.

Au lieu d'aller directement aux vues matérialisées, laissez-moi vous expliquer les vues .

Les vues sont fondamentalement différentes des tables. Si nous voulons masquer certaines colonnes aux utilisateurs, nous ne pouvons pas utiliser de tables. En créant une vue, nous pouvons atteindre la sécurité.

Cas d'utilisation: si une vue est liée en interne à 10 tables avec des fonctions group by et et a des millions de lignes, son exécution prend beaucoup de temps.

Voici donc les vues matérialisées 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 peut être configurée pour s'actualiser automatiquement de manière périodique. Une table peut nécessiter du code supplémentaire pour tronquer / recharger des 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 de code supplémentaire pour tronquer / recharger des données.

La sécurité peut être mieux contrôlée dans une vue matérialisée plutôt que dans un tableau.

Une vue matérialisée est un objet de base de données contenant les résultats d'une requête. Il s'agit de copies locales de données localisées à distance ou utilisées pour créer des tableaux récapitulatifs basés sur des agrégations des données d'un tableau. http://www.oraappdata.com/2016/04/materialized-view.html