Vue matérialisée vs. tableaux: Quels sont les avantages?
il est clair pour moi pourquoi une vue matérialisée est préférable à une simple interrogation d'une table de base. Ce qui n'est pas aussi clair, c'est l'avantage par rapport à la création d'une autre table avec les mêmes données que le MV. Le seul avantage du MV est-il vraiment la facilité de création/maintenance?
n'est-ce pas un MV équivalent à une table avec schéma correspondant et un INSERT dans l'utilisation de la déclaration MVS SELECT?
ce qui signifie que 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 je ne manque rien.
9 réponses
requête Dynamique de réécriture . Les vues matérialisées définissent non seulement les relations, mais vous permettent également de précalculer des jointures coûteuses et des agrégations. L'optimiseur est suffisamment intelligent pour utiliser le MV pour récupérer les données pertinentes même si le MV n'est pas explicitement utilisé dans la requête (paramètres de la base de données, etc.).
votre question a été étiquetée comme Oracle, mais MSSQL fait également des trucs similaires.
ils sont essentiellement équivalents, mais le MV a diverses options pour rafraîchir automatiquement les données, ce qui non seulement améliorer la facilité d'entretien, mais aussi, dans certains cas, l'efficacité, car il peut suivre les changements par ligne.
vues matérialisées peuvent être rafraîchies - ils sont des instantanés de données prises à intervalles réguliers.
votre deuxième déclaration est juste une affaire d'une fois-données est insérée dans la Table à ce moment-là. D'autres changements aux données originales ne sont pas reflétés dans le tableau.
le grand avantage d'une vue matérialisée est la récupération extrêmement rapide de données agrégées, car elle est précomputée et stockée, au détriment de l'insertion/mise à jour/suppression. La base de données maintiendra 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 peut être mise à jour, lorsque vous modifiez la vue matérialisée, elle modifiera aussi la relation de base sur laquelle elle dépend.
en plus des autres réponses (parce que je ne l'ai pas vu), je dirais que bien qu'ils épuisent tous les deux l'espace, la vue matérialisée est logiquement normalisée, tandis que le tableau supplémentaire est logiquement dénormalisé. Si c'est quelque chose qui n'est pas temporaire, vous devrez vous rappeler de mettre à jour la deuxième table chaque fois que vous mettez à jour la table de base.
1) accélérer les opérations d'écriture : comme 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, les frais généraux de maintenance de l'index ont tendance à ralentir le processus d'écriture. Pour éviter cela, vous pouvez créer une vue matérialiser et créer des index sur eux. Ces index peuvent être maintenus en arrière-plan et n'affectent pas négativement les opérations d'écriture de tableau.
2) Speeding read operations : jointures complexes; les pivots qui prennent des âges à exécuter 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 déclaration.
en plus des avantages déjà mentionnés:
- requête dynamique de réécriture (en bref, la DB optimiseur sait comment le MV est créé, de sorte qu'il peut réutiliser afin d'optimiser d'autres requêtes),
- en option, automatique, éventuellement d'actualisation incrémentielle,
j'aimerais mentionner:
- certaines vues matérialisées peuvent être écrites, ce qui met à jour la table source (par exemple les jointures avec les touches primaires peuvent être écrites, au contraire si la vue matérialisée est le résultat d'un groupe par elle ne peut pas être écrite à)
- le serveur de base de données conserve la requête qui a créé les données et pouvez réexécuter. Si vous créez une table, vous avez besoin d'un outil externe (peut-être juste un script personnalisé) réexécuter la requête à chaque fois qu'une actualisation est nécessaire demandé par l'utilisateur. (Je travaille pour une entreprise qui développe un outil qui fait cela et bien plus encore).
la différence entre table et MV est avec table , vous pouvez faire des opérations DML qui seront vues par d'autres utilisateurs alors que les modifications que vous faites à MV ne seront pas disponibles pour d'autres jusqu'à ce que vous mettiez à jour votre serveur de base de données.
MV a un autre avantage lorsque vous construisez MV basé sur plusieurs tables en utilisant des requêtes complexes, les utilisateurs lors de l'utilisation de MV la performance augmente considérablement.