Les index et les vues oracle

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:

---

1 2 3 4

Table PERSONNE ID_PERSONNE number(10) NOM Varchar2(50)

---

Code:

---

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:

---

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:

---

select * from V_ACTIVITE where MANAGER='robert'

---

Tout ce blabla pour en venir à ma question :

Citation:

---

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

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.

Citation:

---

Envoyé par chrifo

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!

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é.

Citation:

---

Envoyé par 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é.

---

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) !!! :D

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 ? :?

Citation:

---

Envoyé par 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é ?

---

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

Citation:

---

Envoyé par kariba

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.

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.

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

Citation:

---

Envoyé par aline

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, ...)

Citation:

---

Envoyé par chrifo

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! :evilred:
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.

Citation:

---

Envoyé par aline

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 :D

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)

1, bien sûr

chrifo :fleche: 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 .

Merci à tous de vos réponses. :)

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