Discussion :

[mister3957]

Bonjour à tous,


J'ai des clients, des dépôts, des visites.

Un client est rattaché à un dépôt.
Une visite est rattaché à un client et à un dépôt.

J'ai besoin de récupérer l'ensemble des clients qui, soit son rattachés à un dépôt particulier, soit on eu une visite qui elle est rattaché à ce dépôt.

La sélection des clients du dépôt est :

Code :

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

1
2
 
SELECT * FROM TBClients WHERE CDepId=25

La sélection des clients qui ne sont pas rattachés à ce dépôt mais qui ont eu une visite rattaché au dépôt est :

Code :

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

1
2
3
4
5
 
SELECT c2.ClientId FROM TBClients c2 WHERE c2.CDepId != 25 AND c2.ClientID IN
(
    SELECT DISTINCT VClientId FROM TBVisites WHERE VDepId = 25
)

Ces deux requêtes sont rapides à exécuter. Par contre, j'aimerai n'en faire qu'une :

Code :

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

1
2
3
4
5
 
SELECT * FROM TBClients WHERE CDepId=25 or ClientId in
(
    SELECT DISTINCT VClientId FROM TBVisites WHERE VDepId = 25
)

Et là ça met 30 secondes à s'exécuter...


Comment je peux faire pour avoir une seule requête ayant la rapidité des deux premières ?


Merci beaucoup;

A bientôt

[CinePhil]

Une requête UNION peut-être ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
SELECT ClientId 
FROM TBClients 
WHERE CDepId=25
 
UNION
 
SELECT c2.ClientId 
FROM TBClients c2 
WHERE c2.CDepId != 25 AND c2.ClientID IN
(
    SELECT DISTINCT VClientId 
    FROM TBVisites 
    WHERE VDepId = 25
)

[bertrand_nt]

Essaye plutot ceci :

Code :

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

1
2
3
4
5
6
SELECT * FROM TBClients WHERE CDepId=25 
Union 
SELECT * FROM TBClients C WHERE EXISTS (SELECT  1 FROM TBVISITES T
                                                            WHERE T.VClientId= C.ClientId
                                                               AND VDepId = 25
                                                            )

- Tu peux également utilisé une fonction
- Il est preférable d'utiliser EXISTS au Lieu de IN

[LeoAnderson]

c'est un jeu de devinettes ?
cool, j'adore ça !

blague à part, on doit deviner les indexes ? les explains plans ? les volumétries ?

l'optimisation de requête, ça ne se fait pas au hasard !!!

[miloux32]

Essaye plutot ceci :

SELECT * FROM TBClients WHERE CDepId=25
Union
SELECT * FROM TBClients C WHERE EXISTS (SELECT 1 FROM TBVISITES T
WHERE T.VClientId= C.ClientId
AND VDepId = 25
)


- Tu peux également utilisé une fonction
- Il est preférable d'utiliser EXISTS au Lieu de IN

Ah non pas d'accord !!!
On m'a toujours dit d'éviter absolument exist dans un SELECT , il est plutot concu pour un update , mais presque tous les exist dans un SELECT peuvent se remplacer par une jointure !

[mister3957]

Bé en tout cas ça fonctionne bien là avec l'union.


Merci

[jmguiche]

Ah non pas d'accord !!!
On m'a toujours dit d'éviter absolument exist dans un SELECT , il est plutot concu pour un update , mais presque tous les exist dans un SELECT peuvent se remplacer par une jointure !

Ben oui, c'est même souvent ce que fait Oracle en terme de plan d'execution ! S'il est possible de remplacer exists par une jointure, il fait "comme si". Et ce depuis toujours. Donc, ce n'est pas la peine de s'en priver.

Et quand ce n'est pas transformable elegament avec une jointure parce que la clause exists ramene plus d'une ligne, les algorithmes utilisé par exists savent s'arreter à la première ligne trouvée, ce qui est parfaitement performant, beaucoup plus qu'un group by artificiel.

Bref, le "on" qui t'a dit ça se prive ( et te prive) d'une fonctionnalité bien efficace et traite des problèmes simple d'une façon bien compliquée.

[mister3957]

Est-ce qu'il y a des bouquins sur l'utilisation du SQL ?

Car moi... J'y connais rien en optimisation de requête. Juste les trucs auquel j'arrive à penser, c'est mettre les conditions qui sont suceptible d'etre négative au début des critères.

Par exemple

Code :

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

1
2
 
SELECT * FROM TABLE WHERE CRIT1=VALEUR1 AND CRIT2=VALEUR2

Si le critère 2 a de forte chance d'être négatif, je préfèrerai le mettre en premier.
Je fais ça en programmation, mais je sais pas si ça fait quelque chose en SQL.

Y'aura pas un bon bouquin qui expliquerai les bonnes pratique du SQL ?


Et est-ce que ces bonnes pratiques sont dépendantes du SGBDR utilisé ?

Merci,

A bientôt

[CinePhil]

Regarde dans les tutoriels de Développez.com

[jmguiche]

Est-ce qu'il y a des bouquins sur l'utilisation du SQL ?

Car moi... J'y connais rien en optimisation de requête. Juste les trucs auquel j'arrive à penser, c'est mettre les conditions qui sont suceptible d'etre négative au début des critères.

Par exemple

Code :

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

1
2
 
SELECT * FROM TABLE WHERE CRIT1=VALEUR1 AND CRIT2=VALEUR2

Si le critère 2 a de forte chance d'être négatif, je préfèrerai le mettre en premier.
Je fais ça en programmation, mais je sais pas si ça fait quelque chose en SQL.

Y'aura pas un bon bouquin qui expliquerai les bonnes pratique du SQL ?


Et est-ce que ces bonnes pratiques sont dépendantes du SGBDR utilisé ?

Merci,

A bientôt

Il fut un temps ou ces considérations faisaient sens, quand l'optimiseur était basé sur des règles. L'ordre des tables dans le from et celui des conditions des clause where pouvaient changer le plan. C'est beaucoup moins vrai, voire pas vrai du tout, avec les optimiseurs statistiques.

[orafrance]

Ah non pas d'accord !!!
On m'a toujours dit d'éviter absolument exist dans un SELECT , il est plutot concu pour un update , mais presque tous les exist dans un SELECT peuvent se remplacer par une jointure !

en réalité il n'y a pas de règle Si la sous-requête du IN ramène peu de ligne alors faut utiliser le IN, sinon le EXISTS est souvent plus avantageux. Mais faut tester

Et le IN comporte un piége puisque les valeurs NULL sont exclues

[orafrance]

Il fut un temps ou ces considérations faisaient sens, quand l'optimiseur était basé sur des règles. L'ordre des tables dans le from et celui des conditions des clause where pouvaient changer le plan. C'est beaucoup moins vrai, voire pas vrai du tout, avec les optimiseurs statistiques.

pas tout à fait... l'ordre peu quand même être important pour les grosses requêtes parce que le nombre de permutations pour trouver le plan d'exécution n'est pas infini... du coup ça peut éviter que le bon plan soit exclu

[orafrance]

Y'aura pas un bon bouquin qui expliquerai les bonnes pratique du SQL ?

si tu commençais par donner les infos demandées par LeoAnderson ce serait pas mal déjà

[LeoAnderson]

j'arrive pas à croire que le sujet soit taggué comme résolu alors qu'on parle toujours dans le vide !

Si il était possible d'optimiser toutes les requêtes par une ré-écriture de codes ou remplace NOT IN pas MINUS, ne croyez-vous pas que le moteur ferait ça tout seul ?
S'il la règle absolue existait, même complexe avec 5000 IF imbriqués, elle serait implémentée en automatique. Et donc, la question ne se poserait pas.

Or, la question se pose. Et il n'y a pas de règle universelle.
C'est pour ça qu'on a besoin d'un minimum d'infos telles que demandées plus haut !

[CinePhil]

Une étude d'optimisation assez édifiante :

Voir aussi son article sur l'optimisation et notamment les chapitres 8 et 9.

[jmguiche]

Est-ce qu'il y a des bouquins sur l'utilisation du SQL ?

Car moi... J'y connais rien en optimisation de requête. Juste les trucs auquel j'arrive à penser, c'est mettre les conditions qui sont suceptible d'etre négative au début des critères.

Par exemple

Code :

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

1
2
 
SELECT * FROM TABLE WHERE CRIT1=VALEUR1 AND CRIT2=VALEUR2

Si le critère 2 a de forte chance d'être négatif, je préfèrerai le mettre en premier.
Je fais ça en programmation, mais je sais pas si ça fait quelque chose en SQL.

Y'aura pas un bon bouquin qui expliquerai les bonnes pratique du SQL ?


Et est-ce que ces bonnes pratiques sont dépendantes du SGBDR utilisé ?

Merci,

A bientôt

Pour comprendre comment ça marche sous oracle, la doc oracle, c'est pas mal. (performance und tuning).
En effet, les problèmes d'optimisations et les bonnes pratiques peuvent varier d'un SGBD à un autre, et même, pour un même sgbd, cela peu changer au fil des versions, soit radicalement : passage d'un optimiseur regle a un optimiseur stat, soit parce qu'il y a des améliorations.

[Jean_Benoit]

J'ai testé la requête originale avec une base de 100000 lignes,

le cost est de 150

Ensuite la requête avec UNION et EXISTS, et un index sur la FK N° de dépot dans la table des clients

le cost est de 15

Ensuite j'ai placé la sous requête dans une clause WITH,

le cost est de 10

WITH customer_visites AS (
SELECT
DISTINCT custno as customer_v
FROM Visites
WHERE depotno = 1010
)
SELECT c.*
from customer_visites cv, customers c
where custno = customer_v
or c.depotno = 1010;