Discussion :

[kariba]

Bonjour,

Je me pose pas mal de questions sur les interactions entre les vues (matérialisées ou non) et les index oracle.

Mettons que l'on ait 2 tables : Personne et Activite :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
Table PERSONNE
ID_PERSONNE number(10)
NOM Varchar2(50)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
Table ACTIVITE
ID_ACTIVITE number(10)
NOM Varchar2(50)
ID_MANAGER number(10) (FK sur l'ID_PERSONNE)

On souhaite une vue V_ACTIVITE qui intégre le nom en toute lettre du manager :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
CREATE OR REPLACE VIEW V_ACTIVITE (ID, ACTIVITE, MANAGER)
AS
SELECT ACTIVITE.ID_ACTIVITE, ACTIVITE.NOM, PERSONNE.NOM
FROM ACTIVITE, PERSONNE
WHERE ID_MANAGER=ID_PERSONNE

Ensuite, je veux chercher toutes les activité dont le manager est 'robert' :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select * from V_ACTIVITE where MANAGER='robert'

Tout ce blabla pour en venir à ma question :

Puis-je optimiser les perfs de cette recherche sur une vue en créant un index sur le nom du manager ?
Il n'est apparement pas possible de créer un index sur la vue elle-même mais est-ce que la vue "bénéficierait" d'un index sur le champ NOM de la table PERSONNE ?

Même question pour une vue matérialisée...

Merci d'avance de vos réponses...

Précisions : je suis en Oracle 10g

[chrifo]

Bonjour,
Effectivement les index se crééent sur les tables. Les vues, qui ne sont ni plus ni moins que des requêtes et s'exécutent (sauf cas particuliers) avec le même plan, peuvent utiliser ces index.
Dans le cas présent, créer un index sur le nom de la personne ne semble pas utile.

[aline]

Dans le cas présent, créer un index sur le nom de la personne ne semble pas utile.

FAUX!

le bon plan d'execution doit taper sur la table user en passant par un index sur le nom de la personne.

Ensuite, il doit faire une nested loop sur la table ACTIVITE et utiliser l'index sur
ID_MANAGER si celui-ci existe évidement!

[chrifo]

hum ... L'intérêt de passer par un index, pour une sélection (et non une jointure), sur cette table qui ne contient que ce champ en plus de la PK ne te parait pas limité ?


Effectivement l'index sur ACTIVITE.ID_MANAGER est quant à lui vivement conseillé.

[kariba]

hum ... L'intérêt de passer par un index, pour une sélection (et non une jointure), sur cette table qui ne contient que ce champ en plus de la PK ne te parait pas limité ?


Effectivement l'index sur ACTIVITE.ID_MANAGER est quant à lui vivement conseillé.

J'ai grandement simplifié les table et la vue pour plus de clarté. Ma vue porte sur plusieures jointures et les tables sont autrement plus conséquentes (et il y a bien des index sur les ID et les FK) !!!

En tout cas, vous semblez confirmer que les clauses where appliquées à une vue s'appuyent sur les index des tables "cachées" par la vue.

Est-ce aussi le cas pour les vues matérialisées ?

[aline]

hum ... L'intérêt de passer par un index, pour une sélection (et non une jointure), sur cette table qui ne contient que ce champ en plus de la PK ne te parait pas limité ?

Tu accèdes à la personne par le champs nom.
Donc mettre un index sur ce champs ne me parait pas du tout limité!

[aline]

Est-ce aussi le cas pour les vues matérialisées ?

Pas du tout!
Ta vue materialisée est une table à part entière.
Pour une requete sur cette table, en général, les tables qui ont servis à la calculer ne te servent plus à rien.

[guigui_cwoco]

1) Les index sur créés sur les tables. Les vues ne sont qu'une autre représentation des données extraites des tables ...

2) Théoriquement l'index sur le champ 'NOM' me semble justifié. Oracle créé automatiquement un index sur chaques primary key, mais dans la cas d'Aline, la recherche se fait par le nom de l'employé et pas par son ID.

Je dis bien théoriquement, j'approuve l'index. Apres, pour les performance, tout dépend du nombre d'employés.

[chrifo]

Effectivement si la structure de la table est plus complexe que celle énoncée l'index sera certainement tout à fait justifié.

Tu accèdes à la personne par le champs nom.
Donc mettre un index sur ce champs ne me parait pas du tout limité!

Très théorique tout ça ... attention toutefois un index créé injustement sur des champs un peu larges d'une table avec beaucoup d'enregistrements peut te poser plus de problèmes qu'il n'optimise ta base (stockage, lenteur de mise à jour, ...)

[aline]

Effectivement si la structure de la table est plus complexe que celle énoncée l'index sera certainement tout à fait justifié.



Très théorique tout ça ... attention toutefois un index créé injustement sur des champs un peu larges d'une table avec beaucoup d'enregistrements peut te poser plus de problèmes qu'il n'optimise ta base (stockage, lenteur de mise à jour, ...)

Je vais finir par m'ennerver!
Ne donne pas de mauvais conseils!
Si ton applis fais des requêtes sur la colonne nom de ta table personne, celle-ci doit être indexé!
Et les problème que tu mentionnes n'en sont pas.

Le cas ou ta table nom comporte 3 personnes est ininteressant.

[kariba]

Pas du tout!
Ta vue materialisée est une table à part entière.
Pour une requete sur cette table, en général, les tables qui ont servis à la calculer ne te servent plus à rien.

Merci pour ces infos Aline

Je déduis de cette remarque 2 cas possibles :

1. Il est possible de créer des index pointant vers une vue matérialisée (à la différence d'une vue simple)
2. Tout accès à une vue matérialisée se fait en FULL SCAN

Quelle est la bonne conclusion ? Le cas 1 ou le 2 ? (J'espère le 1)

[Fabien Celaia]

1, bien sûr

[Jaouad]

chrifo Attention à la pertinence des infos que vous donnez sur le forum

Une table matérialisé à une consistence physique et occupe de la place ( en rapport avec la volumétrie des données ) sur les datafiles , et peut donc être indexé.

Une vue simple n'a pas de consistence physique .

[kariba]

Merci à tous de vos réponses.

Je flag le topic comme résolu.....