Vue matérialisée et tableaux: quels sont les avantages?
Il est clair pour moi pourquoi une vue matérialisée est préférable à la simple interrogation d'une table de base. Ce qui n’est pas aussi clair, c’est l’avantage de créer une autre table avec les mêmes données que le MV. Le seul avantage de la MV est-il vraiment la facilité de création/maintenance?
N'est-ce pas un équivalent MV à une table avec un schéma correspondant et une instruction INSERT INTO utilisant l'instruction MVs SELECT?
Signification, vous pouvez créer un MV comme suit
CREATE MATERIALIZED VIEW ... AS
SELECT * FROM FOO;
Et vous pouvez créer une table équivalente:
CREATE TABLE bar (....);
INSERT INTO bar
SELECT * FROM FOO;
Pour ne pas dire que la facilité de création/maintenance n'est pas un avantage suffisant, je veux juste m'assurer que rien ne me manque.
Réécriture dynamique des requêtes . Les vues matérialisées définissent non seulement les relations, mais vous permettent également de précalculer des jointures et des agrégations coûteuses. L'optimiseur est suffisamment intelligent pour utiliser le MV pour extraire des données pertinentes même si le MV n'est pas explicitement utilisé dans la requête (paramètres de base de données, etc.).
Votre question portait le libellé Oracle, mais MSSQL utilise également des astuces similaires.
Ils sont fondamentalement équivalents, mais le MV a plusieurs options pour actualiser automatiquement les données, ce qui améliore non seulement la facilité de maintenance mais également, dans certains cas, l'efficacité, puisqu'il permet de suivre les modifications par ligne.
Les vues matérialisées peuvent être actualisées - ce sont des instantanés de données prises à intervalles réguliers.
Votre deuxième déclaration n’est qu’une transaction ponctuelle - les données sont insérées dans la table à ce moment-là. Les modifications ultérieures apportées aux données d'origine ne sont pas reflétées dans le tableau.
le gros avantage d'une vue matérialisée est l'extraction extrêmement rapide des données agrégées, car elles sont précalculées et stockées, au détriment de l'insertion, de la mise à jour et de la suppression. La base de données gardera la vue matérialisée en phase avec les données réelles, pas besoin de réinventer la roue, laissez la base de données le faire pour vous.
La vue matérialisée restera synchronisée avec les relations de base Dont elle dépend.
Si la vue matérialisée est modifiable, lorsque vous modifiez la vue matérialisée , Elle modifie également la relation de base dont elle dépend
En plus des avantages déjà mentionnés:
- la réécriture dynamique des requêtes (en résumé, l'optimiseur de base de données sait comment le MV est créé, afin de pouvoir le réutiliser pour optimiser d'autres requêtes),
- rafraîchissement facultatif, automatique, éventuellement incrémentiel,
Je voudrais mentionner:
- il est possible d'écrire sur certaines vues matérialisées, ce qui met à jour la table source (par exemple, les jointures avec des clés primaires peuvent être écrites, à l'inverse si la vue matérialisée est le résultat d'un groupe ne peut pas être écrite)
- le serveur de base de données conserve la requête qui a créé les données et peut le réexécuter. Si vous créez une table, vous avez besoin d'un outil externe (éventuellement d'un script personnalisé) pour réexécuter la requête chaque fois qu'une actualisation est requise/demandée par l'utilisateur. (Je travaille pour une entreprise qui développe un outil qui fait cela et bien plus encore).
1) Accélération des opérations d'écriture : Etant donné que les index peuvent être créés sur des vues matérialisées, leur lecture est très rapide. Notez que si vous créez un index sur une table qui inclut beaucoup d'écritures, la surcharge de maintenance de l'index a tendance à ralentir le processus d'écriture. Pour éviter cela, vous pouvez créer une vue matérialisée et créer des index sur celles-ci. Ces index peuvent être conservés en arrière-plan et n'affectent pas les opérations d'écriture de table.
2) Accélération des opérations de lecture : Jointures complexes; les pivots qui prennent du temps à courir peuvent être accélérés en créant des index sur les vues matérialisées. Cela devient très pratique dans la plupart des scénarios de reporting.
En plus des autres réponses (car je ne l'ai pas vue), je dirais que bien qu'elles utilisent toutes les deux de l'espace, la vue matérialisée est logiquement normalisée, alors que la table supplémentaire est logiquement dénormalisée. S'il s'agit d'un élément non temporaire, vous devez vous rappeler de mettre à jour la deuxième table chaque fois que vous mettez à jour la table de base.
La différence entre table et MV réside dans table. Vous pouvez effectuer des opérations DML qui seront vues par d'autres utilisateurs, tandis que les modifications apportées à MV ne seront disponibles que si vous mettez à jour votre serveur de base de données.
MV présente un autre avantage lorsque vous construisez MV basé sur plusieurs tables à l'aide de requêtes complexes. Les utilisateurs utilisant MV améliorent considérablement les performances.
Les vues matérialisées sont en fait le meilleur choix par rapport aux tables où des agrégations sont nécessaires régulièrement pour afficher les ensembles de résultats mis à jour .. Nous pouvons utiliser une vue matérialisée autre que le stockage du magasin de données dans les modules d’inventaire pour calculer le stock quotidien, hebdomadaire, mensuel avec le solde de clôture requêtes complexes à chaque fois, nous pouvons créer des vues matérialisées pour extraire de tels résultats en un rien de temps.