Optimisation résultat d'une requête

Salut,

j'ai créé une vue qui s'exécute bien mais j'aimerai savoir si la requête est optimale. la vue me permet d'avoir tous les champs de la table SITES_PRESTATAIRE(id, id_site, id_exercice, id_prestataire), mais aussi les champs : nm_site et nm_prestataire. Voici la structure de mes tables.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

----- Table EXERCICES ----   id_exercice nm_exercie   ----- Table PRESTATAIRES -----   id_prestataire nm_prestataire   ----- Table SITES -----   id_site nm_site   ----- Table SITES_PRESTATAIRE -----   id id_site : clé étrangère de la table SITES id_exercice : clé étrangère de la table EXERCICES id_prestataire : clé étrangère de la table PRESTATAIRES

---

ma vue

Code:

---

1 2 3 4 5 6 7 8 9 10

CREATE VIEW VIEW_SITE_PRESTATAIRE AS SELECT SP.id, SP.id_site, S.nm_site, SP.id_exercice, SP.id_prestataire, P.nm_prestataire, SP.dt_prestataire FROM sites_prestataires SP, sites S, prestataires P WHERE SP.id_site = S.id_site AND SP.id_prestataire = P.id_prestataire ORDER BY SP.id, SP.dt_prestataire;

---

C'est juste une requête de création d'une vue. Est-ce que l'order by est nécessaire ? (très probablement non). Sinon j'ai un peu du mal à saisir la portée de votre question.

Pour moi, une vue dans ce cadre est inutile, et même génante. Partons du principe que tes 3 tables sont énormes. Si on a des tables qui font moins de 1000 lignes, tu peux faire cette vue, ça ne gênera rien.
Quand tu vas utiliser cette vue, parfois, tu voudras faire : afficher toutes les lignes avec id_exercice=xxx , d'autres fois, tu voudras afficher toutes les lignes avec id_prestataire=yyy. Et donc Oracle devra utiliser tel plan d'exécution dans un cas, et tel autre plan d'exécution dans un autre cas.

Avec une vue, tu ne pourras pas utiliser de HINTs, tu ne pourras pas 'aider' oracle en lui disant quels indexes utiliser. Souvent, Oracle se débrouillera tout seul et fera les bons choix, mais parfois, il a besoin qu'on l'aide à choisir les bons indexes. Et tu te prives de cette possibilité en cachant tes 3 tables derrière une vue.

Citation:

---

Envoyé par tbc92

Pour moi, une vue dans ce cadre est inutile, et même génante.
...

---

En quoi ? Pourriez-vous expliquer ?

Citation:

---

Envoyé par tbc92

Pour moi, une vue dans ce cadre est inutile, et même génante.
Partons du principe que tes 3 tables sont énormes. Si on a des tables qui font moins de 1000 lignes, tu peux faire cette vue, ça ne gênera rien.
Quand tu vas utiliser cette vue, parfois, tu voudras faire : afficher toutes les lignes avec id_exercice=xxx , d'autres fois, tu voudras afficher toutes les lignes avec id_prestataire=yyy. Et donc Oracle devra utiliser tel plan d'exécution dans un cas, et tel autre plan d'exécution dans un autre cas.
…

---

De où sortez vous vos limites ? Pourriez-vous les démontrer ?

Citation:

---

Envoyé par tbc92

...Avec une vue, tu ne pourras pas utiliser de HINTs, tu ne pourras pas 'aider' oracle en lui disant quels indexes utiliser. Souvent, Oracle se débrouillera tout seul et fera les bons choix, mais parfois, il a besoin qu'on l'aide à choisir les bons indexes. Et tu te prives de cette possibilité en cachant tes 3 tables derrière une vue.

---

Il est toute à fait possible d'injecter des Hints dans les requêtes utilisant des vue. De plus l'utilisation des Hint doit être restreinte à ce qu'elle a été prévu: trouver une solution de contournement d'une manière temporaire.

Citation:

---

Envoyé par tbc92

Avec une vue, tu ne pourras pas utiliser de HINTs, tu ne pourras pas 'aider' oracle en lui disant quels indexes utiliser. Souvent, Oracle se débrouillera tout seul et fera les bons choix, mais parfois, il a besoin qu'on l'aide à choisir les bons indexes. Et tu te prives de cette possibilité en cachant tes 3 tables derrière une vue.

---

Je plussoie ce que dis Mnitu, les hints sont une solution TEMPORAIRE à un problème que l'optimiseur ne peut pas résoudre.
Les hints sont des bombes à retardements qui tordent la main au CBO et l'empêchent de faire le bon choix dans certains cas : exemple, on "force" l'utilisation d'un index via un hint, la requête ramenant 1% des données est plus rapide qu'avant car elle faisait un Full Table Scan. Maintenant la même requête ramène 90% des données (la valeur d'une bind variable a changé) : le fait d'utiliser un hint empêche le CBO de choisir un FTS, il utilise l'index et c'est une catastrophe en terme de perfs...

On peut utiliser des hints pour débugger une requête, comprendre le coût des diverses options (index, FTS) mais ce n'est que très très rarement une solution (exception : le hint DRIVING_SITE).

Citation:

---

Envoyé par mnitu

Sinon j'ai un peu du mal à saisir la portée de votre question.

---

en fait j'ai souvent des requêtes à effectuer sur la table sites_prestataires et j'aimerai que l'utilisateur final lise "le nom du site" au lieu de "id_site" et aussi "le nom du prestataire" au lieu de "id_prestataire". donc j'avais le choix entre toujours exécuter la requête

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

select id, id_site, (select nm_site from sites where id_site = sites_prestataires.id_site) nom_site, id_exercice, id_prestataire, (select nm_prestataire from prestataires where id_prestataire = sites_prestataires.id_prestataire) nom_prestataire, dt_prestataire FROM sites_prestataires ORDER BY id, dt_prestataire;

---

ou bien créer une vue que je pourrais toujours utiliser.

alors ma question est de savoir entre les deux méthodes laquelle est moins gourmande en ressources.

Exécuter une requête directement ou via une vue c'est "bonnet blanc ou blanc bonnet".
A la limite vous devez vérifier selon la distribution des données et le cas d'utilisation si les sous-requêtes scalaire sont vraiment la solution pour remplacer les jointures externes. Et avez vous vraiment besoin des jointures externes ou juste simplement des jointures ?

c'est parce que je ne maitrise pas les jointures dans les requêtes que j'utilise les sous-requêtes scalaires.

C'est bien, maintenant vous savez ce que vous devez apprendre pour vous améliorer.

Donc si je comprends bien, mes requêtes avec les jointures seront plus efficaces que les sous-requêtes scalaires ?

Oui, non, peut-être. On ne peut pas le garantir à priori sinon Oracle pourrait le faire par dessous de la table dans le cadre de l'optimisation comme il le fait souvent quand il peut.
Ce qu'on peut dire c'est juste qu'en principe la requête avec des jointures externes devrait être optimale. Mais dans certains conditions: domaine réduit des valeurs pour les requêtes scalaires et pas de filtre efficace des données via l'accès à ces tables les requêtes scalaires peuvent donner un meilleur résultat suite à un mécanisme d'optimisation propre à Oracle.

Merci de vos différentes réponses.