Discussion :

[magicvinni]

Bonjour,

Il semble que les deux appels :

Code :

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

1
2
 
SELECT SUM(NbConnect) FROM membres JOIN persos ON id = idMembre WHERE sexe = 0

et

Code :

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

1
2
 
SELECT SUM(NbConnect) FROM membres JOIN persos WHERE id = idMembre AND sexe = 0

Soient aussi rapides, du coup quel intérêt voyez-vous (lorsqu'il n'y a que 2 tables) à utiliser ON dans les jointures à part la clarté ?

Merci,
Vincent

[acaumes]

Bonjour,

Je préfère la première version parce que elle sépare clairement les liens entre les tables avec les restrictions sur les résultats.

Cordialement

[SQLpro]

Vieux débat... Lisez ceci :
https://www.developpez.net/forums/d5...-dit-jointure/

Vous comprendrez que ceux qui prônent le WHERE sont des vieux cons à recycler !

A +

[magicvinni]

Bonjour,

Merci pour vos réponses et surtout le lien du débat, je pense aussi qu'il est préférable d'utiliser la première syntaxe, pour les mêmes raisons que acaumes. J'étais juste surpris par les vitesses d’exécutions comparables lors de mes tests. Je clos le sujet en résolu, puisque cette discussion a déjà eu lieu.

Bonne journée à ceux qui prônent le ON, à ceux qui prônent le WHERE et aux autres aussi !

Merci
Vincent

[SQLpro]

J'étais juste surpris par les vitesses d’exécutions comparables lors de mes tests.

Sachez cependant qu'il peut exister une différence d'interprétation et de plan de requête donc de performance, mais le cas est rare. En effet, élaborer un plan de requête optimal est une tâche à très forte complexité (NP difficile) et en pratique l'optimiseur à un temps imparti pour trouver un bon plan, et si ce temps est forclos, alors c'est le dernier plan calculé, pas forcément optimal qui est exécuté. Tout ce qui peut aider à réduire ce temps de calcul est donc bon à prendre afin d'obtenir un meilleur plan.
Or que pensez vous de noyer des opérations de jointure dans une clause SQL (WHERE) en principe dédié à la restriction ?
Ce que va faire l'optimiseur est tout simplement une première passe pour rectifier le plan d'exécution et scinder en deux les opérations de jointure et celle de restriction.
Bien évidemment cette tâche prends du temps au détriment du temps de calcul du plan optimal.
Il arrive donc qu'en de très rare cas, la jointure par JOIN conduise à un plan plus optimal que par le WHERE !

A +

[escartefigue]

[...] en pratique l'optimiseur à un temps imparti pour trouver un bon plan, et si ce temps est forclos, alors c'est le dernier plan calculé, pas forcément optimal qui est exécuté. [...]

Cette remarque très intéressante appelle deux questions :
- s'il n'y a pas de plan précédent applicable, quelle stratégie est choisie au bout du compte ?
- ce principe est il applicable sur l'essentiel des SGBD ?

[SQLpro]

Cette remarque très intéressante appelle deux questions :
- s'il n'y a pas de plan précédent applicable, quelle stratégie est choisie au bout du compte ?
- ce principe est il applicable sur l'essentiel des SGBD ?

Tout dépend des optimiseurs spécifiques à chaque SGBDR... Impossible de répondre de façon unique. par exemple Oracle remet rarement ses plans en cache en cause. SQL Server est très dynamique et dans la prochaine version il sera en auto apprentissage sur les expériences apprises des différentes versions des plans accumulés. Déjà, dans la version actuelle, QueryStore permet d'accumuler tous les plans effectués sur des requêtes similaire et d'en tirer des stats...

A +

[magicvinni]

Merci pour ces précisions fortes enrichissantes,

Vincent

[SQLpro]

Bonjour,

Il semble que les deux appels :

Code :

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

1
2
 
SELECT SUM(NbConnect) FROM membres JOIN persos ON id = idMembre WHERE sexe = 0

et

Code :

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

1
2
 
SELECT SUM(NbConnect) FROM membres JOIN persos WHERE id = idMembre AND sexe = 0

Soient aussi rapides...

ATTENTION, votre 2e requête est syntaxiquement fausse.

Soit vous faites vos jointures à l'aide de JOIN / ON, soit vous faites vos jointures sans JOIN et sans ON en utilisant la clause WHERE. Mais vous ne pouvez pas faire un mix de JOIN et WHERE !


Ceci plante par exemple sous SQL Server conformément à la norme SQL.

A +