Problème de création d'index

Citation:

---

Envoyé par CinePhil

Sur le plan de la logique de la requête, je préfère la première mais pourrait-il y avoir une différence entre les deux sur le plan de l'utilisation des index ?

---

Vu que le résultat n'est pas le même, la réponse est oui. Cependant dans les deux cas, l'idéal est d'avoir un index sur Client(Commercial,Nom). C'est juste que dans le 1er cas, on utilisera l'index en range, et dans le 2ème, on fera une lecture complète de l'index.

C'est dommage que vous n'ayez pas pris le temps d'essayer !

Code:

---

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

CREATE TABLE CLIENT (NOM VARCHAR(8), COMMERCIAL VARCHAR(8))   INSERT INTO CLIENT (NOM, COMMERCIAL) VALUES ('DUPONT', 'BROUARD' ), ('MARTIN', 'CINEPHIL'), ('MULLER', NULL );   CREATE TABLE ADRESSE (NOM VARCHAR(8), VILLE VARCHAR(16))   INSERT INTO ADRESSE (NOM, VILLE) VALUES ('DUPONT', 'LYON'), ('MARTIN', 'PARIS');

---

Code:

---

1 2 3 4 5 6 7 8 9

SELECT C.NOM, A.VILLE FROM CLIENT as C LEFT JOIN ADRESSE as A ON A.NOM = C.NOM WHERE C.COMMERCIAL = 'BROUARD'   NOM VILLE -------- ---------------- DUPONT LYON

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11

SELECT C.NOM, A.VILLE FROM CLIENT as C LEFT JOIN ADRESSE as A ON A.NOM = C.NOM AND C.COMMERCIAL = 'BROUARD'   NOM VILLE -------- ---------------- DUPONT LYON MARTIN NULL MULLER NULL

---

Effectivement, je n'ai pas pris le temps mais en relisant mon message avec mes requêtes supplémentaires après l'avoir écrit, je subodorais un problème ! :oops:

Bref ! C'est le défaut de travailler avec des exemples bidons. Il est évident que je n'aurais jamais écrit la seconde requête dans un cas réel. Ni même la première car je ne ferais pas la jointure sur un nom mais sur un identifiant.

J'espère quand même que vous avez compris le sens de mon interrogation et de mes suppositions concernant l'utilisation des index selon qu'une condition de restriction se trouve dans la condition de jointure ou dans le WHERE.

Nous avons divergé sur le sujet initial de cette discussion, c'était juste par curiosité que je me posais ces questions.

C'est quoi cette indentation pourrie ? j'ai dû mettre au moins 30 minutes à comprendre où était la différence entre les deux requêtes !

Code:

---

1 2 3 4 5 6 7 8 9 10 11

-- Requête 1 : SELECT C.NOM, A.VILLE FROM CLIENT AS C LEFT OUTER JOIN ADRESSE AS A ON A.NOM = C.NOM WHERE C.COMMERCIAL = 'BROUARD';   -- Requête 2 : SELECT C.NOM, A.VILLE FROM CLIENT AS C LEFT OUTER JOIN ADRESSE AS A ON A.NOM = C.NOM AND C.COMMERCIAL = BROUARD';

---

C'est quand même plus lisible non ?

Sinon, filtrer une autre table que la table jointe dans la clause ON, je savais même pas que c'était supporté.
C'est standard ?

Après mûre réflexion, ça peut avoir son utilité (je dirais même que si Oracle le supporte, je devrais pouvoir amplement simplifier des requêtes de taré que j'ai écrit) mais en revanche, c'est tout sauf lisible et évident...

Citation:

---

Envoyé par StringBuilder

Sinon, filtrer une autre table que la table jointe dans la clause ON, je savais même pas que c'était supporté.
C'est standard ?

---

Standard au sens détail de la norme SQL, je ne sais pas, mais Oracle et SQL Server le supportent.

La requete 2 va générer beaucoup + de lectures logiques...pas sur que ce soit donc un gain de temps en environnement de production

À partir du moment où les 2 requêtes n'ont pas le même périmètre (la 2ème requête ramenant toute la table Client), est-il vraiment pertinent de comparer les performances des deux ?

Citation:

---

Envoyé par StringBuilder

Sinon, filtrer une autre table que la table jointe dans la clause ON, je savais même pas que c'était supporté.

---

Une jointure concerne toujours au moins deux tables.

Citation:

---

Envoyé par Waldar

Une jointure concerne toujours au moins deux tables.

---

Ce ne serait pas plutôt:
Une jointure concerne TOUJOURS 2 tables ?

Je ne vois pas trop comment faire une jointure avec 3 tables.

Tatayo.

Si on est sur les mots, j'ai dit une autre bêtise, vu qu'on peut faire des auto-jointures.

En écrivant le mot toujours j'avais en tête ce genre de jointures :

Code:

---

1 2 3 4 5 6

FROM A INNER JOIN B ON B.id = A.id INNER JOIN C ON C.col1 = B.col1 AND C.col2 = A.col3

---

Citation:

---

Envoyé par Waldar

Si on est sur les mots, j'ai dit une autre bêtise, vu qu'on peut faire des auto-jointures.

---

On peut même faire des non-jointures !

Par exemple :

Code:

---

1 2 3 4 5

SELECT * FROM A LEFT JOIN B ON (1 = 0)

---

Waldar => Effectivement, dans ce cas la deuxième jointure porte sur 3 tables. J'etais resté sur une requête avec une jointure... hypothèse du mode clos, fin de semaine, tout ça... :aie:

Tatayo.

Non, mais ce qui me choque, c'est que l'on puisse, dans le ON filtrer un sous-ensemble de la table référante :

Code:

---

1 2 3 4

select * from referante left outer join referee on referee.fk_id = referante.id and referante.champ = 'filtre';

---

Ce qui se traduit littéralement par :

Citation:

---

Récupère-moi toutes les lignes de la table référante, ainsi que les lignes de la table référées uniquement lorsque champ champ de la table référante est égale à filtre.

---

C'est à dire qu'on va faire un LEFT OUTER JOIN partiel, qui ne porte que sur un sous-ensemble de la table référante. J'aurais jamais imaginé que ça puisse marcher !

C'est à dire, en d'autres termes "ramène-moi tous les clients, ainsi que les adresses de seulement ceux qui ont 20 ans".
Habituellement, c'est plutôt "ramène-moi tous les clients, ainsi que les adresses de seulement ceux qui habitent Lyon", ce qui est loin d'être la même chose.

Jusqu'à présent, j'aurai écrit ce truc ignoble, sous Oracle :

Code:

---

1 2 3 4

select * from client left outer join adresse on adresse.client_id = decode(client.age, 20, client.id, null);

---

Je ne trouve pas que ce soit si choquant (à part dans cet exemple !), et d'ailleuirs j'ai un exemple concret:
Dans une application de réassort, je traite des articles "centralisés", et des articles direct fournisseur.
Comme le fournisseur des produits centralisés est caché aux utilisateur, je ne dois afficher le fournisseur que pour les articles "direct fournisseur":
En simplifiant la requête

Code:

---

1 2 3 4

select article.reference,fournisseur.code from article left outer join frn_art on frn_art.idart = article.id and article.centralise = faux

---

literralement: récupère moi les articles, et le fournisseur uniquement pour les produits non centralisés.

Tatayo.