Non, l'opérateur JOIN n'est pas "strictement identique".
Pour le résultat, ce sera effectivement pareil, mais l'optimiseur peut traiter différemment le = et le "[INNER] JOIN".
Par exemple, dans tous les SGBD que je connais, l'optimiseur syntaxique ne considère pas que la relation "=" est transitive. Donc si on fait une requete de type :
A.id = B.id
AND B.id = C.id
l'optimiseur syntaxique n'en déduit pas que
A.id = C.id
Du coup, lorsque l'optimiseur statitistique évaluera les plans d'exécutions possibles, il évaluera le plan en utilisant A ou C comme table directrice, mais jamais B. (quand on sait ce qu'on fait, ça peut être pratique pour blouzer l'optimizeur, mais 99 fois sur 100, c'est une mauvaise idée).
Pourquoi le "=" n'est pas transitif ? Parce que sinon on arrive à des combinatoires trop complexes pour le choix du plan d'exécution. Par exemple si je fais :
WHERE client.id = commandes.client_id
AND client.id = 12345
Il faudrait que l'optimiseur evalue également :
client.id = commandes.client_id
AND commandes.client_id = 12345
et donc qu'il évalue aussi :
WHERE commandes.client_id = client.id
AND client.id = 12345
et
WHERE commandes.client_id = client.id
AND commandes.client_id = 12345
(choix de table directrice)
Pour peu que la jointure soit faite sur 4 tables, et qu'il y ait 2 ou 3 gags de ce genre, le SGBD va passer plus longtemps à évaluer des plans d'exécution qu'à effectuer des requêtes :o)
Par contre, un optimiseur syntaxique (voire statistique), PEUT tout à fait traiter différemment le JOIN. Et si l'optimiseur est codé pour le faire, il choisira le plan d'exécution plus intelligemment qu'avec des "=".
[^] # Re: kexi: un Access-like sous KDE
Posté par aegir_lf . En réponse à la dépêche kexi: un Access-like sous KDE. Évalué à 7.
Pour le résultat, ce sera effectivement pareil, mais l'optimiseur peut traiter différemment le = et le "[INNER] JOIN".
Par exemple, dans tous les SGBD que je connais, l'optimiseur syntaxique ne considère pas que la relation "=" est transitive. Donc si on fait une requete de type :
A.id = B.id
AND B.id = C.id
l'optimiseur syntaxique n'en déduit pas que
A.id = C.id
Du coup, lorsque l'optimiseur statitistique évaluera les plans d'exécutions possibles, il évaluera le plan en utilisant A ou C comme table directrice, mais jamais B. (quand on sait ce qu'on fait, ça peut être pratique pour blouzer l'optimizeur, mais 99 fois sur 100, c'est une mauvaise idée).
Pourquoi le "=" n'est pas transitif ? Parce que sinon on arrive à des combinatoires trop complexes pour le choix du plan d'exécution. Par exemple si je fais :
WHERE client.id = commandes.client_id
AND client.id = 12345
Il faudrait que l'optimiseur evalue également :
client.id = commandes.client_id
AND commandes.client_id = 12345
et donc qu'il évalue aussi :
WHERE commandes.client_id = client.id
AND client.id = 12345
et
WHERE commandes.client_id = client.id
AND commandes.client_id = 12345
(choix de table directrice)
Pour peu que la jointure soit faite sur 4 tables, et qu'il y ait 2 ou 3 gags de ce genre, le SGBD va passer plus longtemps à évaluer des plans d'exécution qu'à effectuer des requêtes :o)
Par contre, un optimiseur syntaxique (voire statistique), PEUT tout à fait traiter différemment le JOIN. Et si l'optimiseur est codé pour le faire, il choisira le plan d'exécution plus intelligemment qu'avec des "=".