Les performances de la base de vue vs nouvelle table

Je suis en utilisant une base de données Oracle qui est d'avoir ralentir les performances en raison de la rejoint sur certains tableaux pour obtenir des résultats. J'envisage de faire une nouvelle table qui stocke certaines de ces données de sorte qu'il peut être récupéré rapidement, sans avoir à effectuer des jointures. Une autre alternative est de créer une vue pour les jointures, je m'exécute et puis toujours interroger le point de vue des données. Quelle est la différence entre les résultats obtenus à l'aide d'une nouvelle table et la création d'un point de vue? J'ai pensé d'un point de vue encore besoin de courir la rejoindre si elle ne serait pas de l'offre que de bonnes performances dans une nouvelle table.

D'Info sur base de données Oracle point de vue est ici:
- http://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_8004.htm
- Ce qui est une Vue de l'Oracle?

Des éclaircissements sur la base des réponses ci-dessous. Les requêtes sont principalement optimisé déjà donc je ne veux pas faire de l'optimisation. Préférez une table ou d'une vue matérialisée, mais je voudrais savoir ce qui pourrait être mieux. Je suis intéressé par la performance. Écrire plus de code à maintenir le nouveau tableau en synchronisation avec les anciennes tables n'est pas un problème. Je vais juste ajouter des instructions de modification de partout où des modifications ont été effectuées afin de vieux tableaux. Je ne veux pas utiliser une vue matérialisée si il est plus lent que l'ajout d'une nouvelle table.

La différence est que l'actualisation des données est plus efficace pour la vue matérialisée ou pour une nouvelle table. Pour la nouvelle table, en gros je vais être en ajoutant de mettre à jour les énoncés où il y avait des mises à jour de l'ancienne table. Ainsi, lorsque l'utilisateur interroge le nouveau tableau, les données sont déjà là (aucun traitement supplémentaire n'est nécessaire). Mais pour une vue matérialisée, si l'affichage s'actualise lui-même que lorsque l'utilisateur interroge le point de vue, alors ce pourrait être plus lente.

La vue affiche les données en fonction d'une requête. Cela évite de réplication de données et permet d'économiser votre espace de stockage au lieu de créer une nouvelle table. Je pense que pour le problème de performance look à la requête de l'optimisation.
Je pense que u veux dire de la vue matérialisée, non?
Oh, besoin de regarder la différence, j'ai commencé à utiliser oracle. Je n'utilise que du simple point de vue, comme CREATE VIEW
Est votre problème que vous avez beaucoup de requêtes compliquées que tous les travaux OK séparément, mais effectuer horriblement lorsque vous les combinez?
Votre argument: "ralentir les performances en raison de jointures" n'est pas convaincante. Habituellement, correctement présenté index, jointures sont exécutées en tant que indexées de boucles imbriquées. Par conséquent, il n'y a pas de raison fondamentale pour vos requêtes avec des jointures doivent être beaucoup plus lent que simpliste requêtes (select à partir d'une table avec une seule table de prédicats).

OriginalL'auteur john | 2012-03-12

7

Vue est juste une requête stockée donc il devrait y avoir aucune différence de performance entre l'interrogation d'une vue et de l'émission d'une requête identiques aux tables de base.

La création d'un tableau à part, peut améliorer les performances des requêtes, mais il viole la normalisation et ensuite, vous devez écrire du code qui maintient cette table en synchronisation. Si vous avez besoin des requêtes pour obtenir le résultat correct plutôt qu'un résultat approximatif, ce qui signifie que vos opérations DML (insertions, mises à jour et suppressions) vont être plus lent pour traiter de conserver les données à synchroniser. Que peut être un bon compromis si cela est principalement une base de données de rapports, mais il va être beaucoup moins approprié dans un environnement OLTP où l'opération de la performance est critique.

Si vous allez créer une table, j'avais généralement suggèrent que vous regardez à la création d'un vue matérialisée à la place. Qui a les avantages de performance d'une table, mais Oracle prend soin de garder la synchronisation de sorte que vous n'avez pas à écrire beaucoup de code personnalisé.

Mais ce n'est pas du tout évident que la concrétisation des données est la bonne solution, en premier lieu. Êtes-vous certain que vous n'êtes pas tout simplement manque quelques indices?

Mais les vues matérialisées ne peut pas être rapide actualisé sur des requêtes complexes, et ce serait un problème. Si il veut plein d'actualisation d'une MV sur chaque DML, alors que le gain de l'utilisation de MV?
Le gain, c'est que vous n'avez pas à écrire, à maintenir et à déboguer un tas de code pour essayer de garder la matérialisée données en synchronisation avec les données sous-jacentes. Si vous avez une requête complexe que l'Oracle ne peut pas créer un rapide actualisable vue matérialisée, vous allez avoir de la difficulté à développer le code de garder le matérialisée de données cohérentes.
D'accord, mais je crois que l'optimisation de la requête est la première chose ha est fait, la plupart du temps, l'optimisation de la requête est la réponse.
Je suis d'accord que l'optimisation de la requête est probablement la meilleure réponse. C'est pourquoi j'ai inclus dans ma réponse à la question de savoir si la concrétisation des données est la bonne solution, en premier lieu.
Des précisions. C'est essentiellement une base de données de rapports (il est utilisé pour faire un peu d'histoire à la comparaison de plusieurs éléments de données) donc pas un environnement OLTP. Les requêtes sont principalement optimisé déjà donc je ne veux pas faire de l'optimisation. Préférez une table ou d'une vue matérialisée, mais je voudrais savoir ce qui pourrait être mieux. Merci.

OriginalL'auteur Justin Cave
5

Un materialized view peut-être ce que vous cherchez. Régulièrement view n'existe pas comme un tableau, c'est juste des références aux tables il est basé sur. Mais, comme Linutis commenté, vous devriez essayer d'optimiser votre requête. Vous pouvez avoir besoin des index sur les colonnes impliquées dans la jointure, et les statistiques recueillies sur les tables que vous utilisez.

OriginalL'auteur GriffeyDog
5

Vues sont juste un wrapper pour les requêtes, les performances de l'utilisation de la vue est la même que la performance de l'aide d'une requête (si vous l'ignorez requête d'analyse généraux).

Donc à l'aide d'un point de vue ne va pas aider votre problème, si vous utilisez beaucoup de jointures. Mais après beaucoup d'expérience dans l'optimisation de la requête à l'Oracle, je peux vous donner quelques remarques:
1. Utilisation d'une sous-sélection (à l'intérieur de votre clause select) au lieu de rejoindre lorsque cela est possible; il existe des cas où cela ne peut pas être fait, ou il n'est pas bon de le faire, tels que:
  - lorsque vous utilisez des jointures internes à supprimer certains enregistrements de jeu de résultats -
  - vous voulez avoir des conditions sur des colonnes
  - vous souhaitez effectuer le tri des colonnes.
2. Utilisation union all au lieu de union où il peut être fait.
3. Utilisation coalesce quand il est bon, (même l'utiliser avec des sous-sélectionnez paramètres),
4. Créer des index appropriés (selon votre plan d'exécution)
5. Éviter stockées à l'aide de fonctions dans votre jointure et les clauses where.
Ce sont les choses qui est venu à mon esprit maintenant. Espérons qu'il allait les aider.

OriginalL'auteur Amir Pashazadeh

Vous devez vous connecter pour publier un commentaire.