Discussion :

[Jhulk]

Bonjour à tous,

Je ne poste pas cette discussion dans le débat concernant les jointures car il parle plus des différences de syntaxes.

Ma question tourne plus autour des performances théoriques de comment on ordonne ses jointures.

Si on prend l'exemple d'une structure classique :
- Table commande : ORDER
- Table ligne de commande : ORDER_L

Donc avec plusieurs lignes de commandes par commande.

Même si (selon le SGBD) l'optimisateur est censé faire le taff je n'ai jamais sû s'il fallait rédiger sa requête :

Type 1 :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
SELECT
	ORDER.ID_ORDER,
	ORDER.TITLE,
	ORDER_L.PRODUCT,
	ORDER_L.QUANTITY
 
FROM ORDER
 
JOIN ORDER_L ON
	ORDER_L.ID_ORDER = ORDER.ID_ORDER
 
WHERE ORDER.ID_ORDER = '424242'

Ou type 2 :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
SELECT
	ORDER.ID_ORDER,
	ORDER.TITLE,
	ORDER_L.PRODUCT,
	ORDER_L.QUANTITY
 
FROM ORDER_L
 
JOIN ORDER ON
	ORDER_L.ID_ORDER = ORDER.ID_ORDER
 
WHERE ORDER.ID_ORDER = '424242'

J'ai toujours choisis par défaut le type 1 , parce qu'intuitivement je le trouve plus logique.

Je ne parle pas des cas d'exceptions ou on tombe sur une commande qui n'a pas de ligne ( de toute façon je n'ai pas mis de jointure en outer dans mon exemple).

Mais de votre expérience : faut-il partir de la table qui renverra "n" records pour 1 ID et joindre vers la table qui n'a qu'un record pour un ID ou l'inverse ?

[Oishiiii]

Il faut bien distinguer le SQL, qui se situe à un niveau logique; le QUOI et l'aspect algorithmique, l'optimiseur, qui traite du COMMENT.

C'est le principe d'indépendance physique qui a fait le succès de la Théorie Relationnelle, en permettant à l'utilisateur d'écrire une jointure de la même façon depuis 40 ans, tout en laissant les SDGB modifier leurs algorithmes au fil des années pour améliorer les performances.

Donc en termes de SQL, l'opérateur de jointure étant commutatif, c'est bonnet blanc, blanc bonnet.

Côté performance, l'optimiseur fera toujours le meilleur choix, après en fonction du SGBD, des statistiques, de l’environnement, la technique choisie peut varier. Il faut vérifier en comparant les plans d’exécution.

[Jhulk]

Donc pour faire simple, il n'y a pas de règle générale, il faut benchmarker chaque requête en regardant les coûts dans les plans d'exec.

C'est bien ce que je craignais. :-/

[Oishiiii]

Pour des requêtes extrêmement simples comme celles-ci il n'y a même pas besoin de se poser de question.

De manière générale dans 99.9% des cas, il n'y a pas besoin de vérifier le plan d’exécution pour chaque requête SQL que vous écrivez.
C'est seulement au cas par cas, quand le temps d’exécution semble anormalement long que l'on va investiguer et chercher à optimiser (en modifiant la requête, en posant des index, etc..).

[SQLpro]

Donc pour faire simple, il n'y a pas de règle générale, il faut benchmarker chaque requête en regardant les coûts dans les plans d'exec.

C'est bien ce que je craignais. :-/

NON !!!!

Il n'y a qu'une seule règle : l'ordre des jointures n'a STRICTEMENT AUCUN INTÉRÊT !

A +

[SergioMaster]

Bonjour,

Il n'y a qu'une seule règle : l'ordre des jointures n'a STRICTEMENT AUCUN INTÉRÊT !

sauf peut être à la lecture humaine

[aieeeuuuuu]

Il n'y a qu'une seule règle : l'ordre des jointures n'a STRICTEMENT AUCUN INTÉRÊT !

ça, c'est dans la théorie. Dans la pratique, avec un nombre de tables plus élevé, ça peut influencer l'optimiseur et deux requêtes sémantiquement identiques avec juste une inversion de l'ordre des jointures peuvent - rarement - conduire à deux plans d’exécution différents.

[SQLpro]

Oui si tu as un mauvais SGBD comme MySQ merde.... Sinon, c'est plus que très rare dans un bon SGBDR... Pour ma part jamais vu !

A +