Dans le monde d'Oracle, j'ai l'impression que les vues basées sur d'autres points de vue sont considérées comme une mauvaise pratique. Je me suis moi-même plaint lorsque l'essai de résoudre les problèmes de performance et que l'imbrication semblait excessive et se cache une complexité inutile dans les vues sous-jacentes. Maintenant, je me trouve dans la situation de penser que cela peut ne pas être si clair: p>
J'ai des utilisateurs qui ont très spécifiquement besoin de numéros de comptabilité à partir d'une vue pour correspondre à ceux d'un autre qui traite encore d'eux. S'ils changent jamais quelque chose en un, ils veulent que l'autre reflète cela immédiatement, sans que quiconque ait à penser à cette exigence dans quelques années de temps et de rapports montrant des chiffres non assortis pendant qu'ils incitent les choses. P>
est-ce que ça va de nier la vue dans ce cas? P>
Cela change-t-il des choses si la vue intérieure contient une autre vue importante contenant des prix pertinents (c'est-à-dire que vous êtes "toujours" censé utiliser ce point de vue lors de la détermination des prix)? P>
10 Réponses :
Les meilleures pratiques ne couvrent pas toujours tout. Je pense que vous avez une justification précise pour les nidifier, juste une fois. P>
C'est aussi une bonne chose à noter dans le processus de construction de requêtes de base de données compliquées, parfois des vues imbriquées sont la meilleure chose - pour un exemple, si vous avez besoin d'un opérateur de mathématiques construit sur 2 colonnes, par exemple SUM (COL1, COL2) peut être préférable de nier la vue afin que la somme soit une colonne en elle-même au lieu de faire quelque chose comme p>
"Sélectionnez Total / Somme (Col1, Col2), Somme (Col1, Col2) * 2, Col1 / Somme (Col1, Col2) ..." P>
Cependant, je ne suis pas sûr de comprendre 100% - pourquoi y a-t-il des vues nécessaires? Les deux utilisateurs ne peuvent pas examiner la vue et le traitement ultérieur de la vue d'une autre couche au-dessus de celui-ci? P>
Je suis imbriquant des vues 3 niveaux profonds dans Oracle 10G R2. Les performances semblent corrélées aux énoncés Sélectionner dans les vues, plutôt que la profondeur de la vue. En particulier, la clause "IN" semble causer beaucoup de problèmes. P>
"In 'est sémantiquement équivalent à une série d'opérateurs" ou ". Les prédicats ou 'ou' ne sont pas Sarg-capables (un terme SQL Server Signification qu'un prédicat peut être résolu à l'aide d'un index), bien que les optimisateurs modernes s'améliorent pour les traduire en quelque chose qui peut être résolu de cette manière.
Je pense que vous êtes sur la pente glissante ici où la réutilisation et la performance du code vont s'affronter. Vous pouvez l'essayer et voir à quel point il affecte la performance. Nous avons un couple de bases de données ici où ils ont empilé des vues sur les points de vue et, franchement, la performance est misérable et que tout le monde impliquait maintenant, ils n'avaient pas conçu de cette façon. P>
Tout comme tout ce qu'il peut être maltraité. La très bonne chose à propos des vues est que vous pouvez modifier la mise en œuvre (requête pour la vue, ainsi que la structure de table sous-jacente) sans affecter l'interface. Je ne suivrais pas aveuglément une politique juste pour le bien de la politique.
Les meilleures raisons d'utiliser une vue serait de: p>
Je me rends compte qu'il peut également aider à simplifier une requête plus complexe, mais vous l'utilisez. Vous pouvez constater qu'une fonction définie par l'utilisateur (tableau) peut être une meilleure solution. De toute façon, la performance prendra un coup. P>
Il y a toujours un compromis entre le temps de codage, la facilité ou la qualité du code et la performance. P>
Les vues de nidification sont vraiment faciles à coder et, étant donné les bonnes circonstances, facilite la lecture. Cela peut également réduire le temps. Cela permet de réduire sans doute la qualité et réduit souvent la performance ... mais de combien? P>
C'est tout subjectif. Si cela a du sens, roulez-le avec. Ne pas optimiser prématurément votre code. P>
Le principal problème avec les vues de nidification est que l'optimisateur de requête est plus susceptible de devenir confus et de produire un plan sous-optimal. En dehors de cela, il n'y a pas de surcharge spécifique pour utiliser des vues sur des vues à moins qu'ils ne font quelque chose que l'optimisateur ne peut pas pousser les prédicats dans. P>
Cela signifie que la meilleure option est d'essayer les vues imbriquées. Voyez si vous obtenez des plans de requête raisonnables hors des rapports. Si cela cause des problèmes, vous devrez peut-être repenser votre stratégie. P>
+1, la meilleure façon de répondre à ce type de question est de l'essayer et de mesurer l'impact de la performance. Expliquer le plan est votre ami.
Les vues imbriquées peuvent avoir un sens. Veillez simplement à ce que vous ne les rendiez pas trop généraux.
J'ai vu un système qui avait une vue avec 14 tableaux mentionnés explicitement, certains d'entre eux sont liés aux auto-jointures extérieures, et certaines des tables 'étaient eux-mêmes des points de vue. Je ne l'aimais pas beaucoup, mais le SGBD l'a imbriquée étonnamment bien (étant donné qu'il était de retour à la fin des années 80). Beaucoup de schéma était généré par un outil de modélisation de données. P> La notation de jointure extérieure est spécifique à Informix (qui prend également en charge la notation standard SQL). P> Notez que IBB_V_POST_RESP2 et IBB_V_PROJ_CO2 sont eux-mêmes des points de vue.
En fait, IBB_V_PROJ_CO2 était une vue de 3 table, détails exacts inconnus mais de
la forme: p> ceci signifie que la vue IBB_V_PROJECT a une jointure externe
Ibb_project. La vue IBB_V_POST_RESP2 a probablement impliqué 3 tables
aussi (mes notes sur ceux qui étaient un peu floues, du retour en 1993, lorsque j'ai enregistré ces informations). P> CREATE VIEW IBB_V_Post_Resp2 AS
SELECT A.Person_Iref,
A.Some_Other_Col col01,
B.Xxxx_Iref,
B.Some_Other_Col col02,
C.Yyyy_Iref,
C.Some_Other_Col col03
FROM IBB_Personnel A,
IBB_R_Xxxx B,
IBB_R_Yyyy C
WHERE A.Xxxx_Iref = B.Xxxx_Iref
AND B.Yyyy_Iref = C.Yyyy_Iref;
Je vais juste répondre d'une perspective des meilleures pratiques: p>
Il n'y en a que quelques fois, je pause d'utiliser des vues sur les vues. P>
La nidification semble être hors de la main ... comme plus de 3 niveaux profonds. La raison pour laquelle je nie est de rendre le code plus facile à maintenir. Dès que je commence à arriver à ce point, cela commence à se sentir un peu trop compliqué à comprendre. P> li>
Niblage d'une vue qui utilise des fonctions analytiques. Personnellement, pour une raison ou une autre, j'ai eu une très bonne expérience avec des vues de nidification avec une fonction analytique. P> li>
Vues de nidification qui font des analyses complètes par nature. Bien que je pense que l'optimiseur de la requête est probablement assez intelligente de gérer cela, cela me semble tort lorsque j'examine la logique de la vue. P> Li>
performance est une grande préoccupation. Cela ne veut pas dire que l'optimiseur pourrait vous tromper, mais c'est à dire avant de le relâcher, je vais le tester pour voir si je ne peux pas comprendre un moyen plus rapide de le faire. P> Li > ol>
Autre que cela j'ai utilisé des vues sur des points de vue avec succès. P>
ne veux pas vraiment me faire prendre dans toute la vue imbriquée p>
Pensez-y à cette idée pour une idée ... Vous essayez de rejoindre une table pour trouver des incompatibles ... J'utiliserais la fonction Oracle 'Minus' .... moins sélectionne les éléments de la première table, puis supprime Des lignes qui sont également retournées par la deuxième déclaration de sélection. p>
Sélectionnez NUM De (sélectionnez 1 comme num De Dual Union tout Sélectionnez 2 comme num De Dual Union tout Sélectionnez 3 comme num Dual) Base_View P>
moins p>
Sélectionnez 2 comme num De Dual P>
Merci pour la réponse, mais ce n'est pas réellement ce que je veux - il y aura deux rapports qui répertorient chaque liste de différents types d'informations (par le groupe), mais ils doivent correspondre exactement (en totaux). Il n'est pas utilisé pour la détection des divergences, les deux sont nécessaires à leurs propres fins, mais elles doivent toujours être fondées sur les mêmes chiffres, même si les règles de ces chiffres changent légèrement à l'avenir.
+1, bonne question, beaucoup d'opinions que vous pouvez voir. Probablement pas une réponse unique.