Discussion :

[remdel59]

Bonjour,

J'ai 2 questions portant sur la performance des requêtes SQL :

- Mieux vaut-il faire une seule "grosse" requête (avec des jointures et des sous requêtes) que de faire plusieurs petites requêtes les unes à la suite des autres ?

Je me dis que logiquement une grosse requête devrait être plus optimisée notamment car nous n'appelons qu'une fois notre sgbd mais cependant la requête est moins "maintenable"

- Ensuite dans le cas où il serait plus judicieux de faire une grosse requête, pourriez-vous me dire la différence qu'il y a entre ces 2 requêtes :

Modèle utilisé :
SALARIE
salarie_id
salarie_name

SALARIE_BUREAU
id
salarie_id
bureau_id

BUREAU
bureau_id

"

Code :

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

1
2
SELECT bureau_id FROM salarie_bureau WHERE salarie_id =
                              SELECT salarie_id FROM salarie WHERE salarie_name = 'toto';

"

ou

"

Code :

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

1
2
3
SELECT bureau_id FROM salarie_bureau 
                              INNER JOIN salarie ON salarie_bureau.salarie_id = salarie.salarie_id
                              WHERE salarie.name = 'toto'

;

La première est une requête imbriquée, l'autre avec jointure. Ces 2 requêtes donnent-elles toujours le même résultat ? Quelle serait la plus performante des 2 ?

Merci d'avance !

remdel

[StringBuilder]

Il faut privilégier la réduction du nombre de requêtes, surtout lorsqu'elles sont indissociables : par exemple, il ne faut surtout pas chercher dans une requête l'identifiant d'un élément, et d'aller chercher les informations de l'élément dans une requête suivante, d'autant que généralement ça va te demander à faire plusieurs fois de suite les mêmes requêtes.

Ensuite, il faut toujours privilégier au maximum les jointures (avec la norme SQL92, que tu as utilisé), plutôt que des sous-requêtes. D'autant que ta sous-requête peut provoquer des erreurs : il faut toujours utiliser champ IN (select ...) ou à la limite champ = (select MAX(...) ...)

[CinePhil]

Il est évident qu'ici il faut faire une jointure !

Le cas où il peut être plus intéressant de faire une sous requête est la recherche d'une existence ou d'une non existence.

Par exemple, si tu recherches les bureaux inoccupés :

Code :

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

1
2
3
4
5
6
7
8
SELECT b.bureau_id
FROM BUREAU b
WHERE NOT EXISTS
(
	SELECT *
	FROM SALARIE_BUREAU sb
	WHERE sb.bureau_id = b.bureau_id
)

La requête précédente sera peut-être plus performante, s'il y a beaucoup de données, que cette requête avec jointure :

Code :

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

1
2
3
4
SELECT b.bureau_id
FROM BUREAU b
LEFT OUTER JOIN SALARIE_BUREAU sb ON sb.bureau_id = b.bureau_id
WHERE sb.bureau_id IS NULL

[remdel59]

D'accord merci à vous 2 pour vos réponses !

Concernant le choix entre la jointure ou la sous requête c'est :
J'utilise la sous requête doit être utilisée lorsque je cherche à savoir si j'ai 0 ou 1 résultat et la jointure dans tous les autres cas c'est bien ça ?

Remdel

[StringBuilder]

Non, pour faire une jointure quand tu as 0 ou 1 élément joint, il faut faire un LEFT OUTER JOIN.
Les cas d'utilisation de sous-requête sont pour :
- Tester l'existence d'une donnée, sans forcément qu'un lien existe explicitement. Par exemple rechercher tous les clients qui n'ont pas passé de commande de champagne depuis plus de 6 mois => Avec une jointure, ça ne sera pas très clair à la relecture.
- On ne veut pas utiliser une requête analytique pour retrouver par exemple le détail de la commande qui le plus gros montant depuis le début du mois.

En gros, dès que tu peux t'en passer, passe-t'en. Les problèmes de performances entre sous-requête et jointures/fonctions analytiques sont généralement en défaveur de la sous-requête, et cela varie pas mal d'un SGBD à l'autre.
Le seul intérêt des sous-requêtes, quand on a l'habitude d'en utiliser, c'est qu'elles peuvent parraîtres plus claires à lire. Mais en programmation, c'est un bien pâle argument.

[remdel59]

J'ai un peu de mal à saisir la différence entre "Tester l'existence d'une donnée" et tester si j'ai "0 ou 1 élement joint".

Je vais prendre un cas concret. Soit le modèle suivant :

User
user_id
user_name

SalleSecurisee
salle_id
salle_name

UserSalleSecurisee
user_id
salle_id

Si une ligne est présente dans la table UserSalleSecurisee cela signifie que l'utilisateur a le droit d'accès à cette salle. Sinon il n'en a pas le droit.

Je souhaite via une requête savoir si l'user "toto" a accès à la salle sécurisée "bunker". Cela revient à tester l'existence d'une ligne dans la table UserSalleSecurisee ou encore de vérifier s'il y a 0 ou 1 résultat.

2 requètes possibles :
Avec une sous requête

Code :

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

1
2
3
4
5
6
 
Select * From UserSalleSecurisee uss
	     Where uss.salle_id = 
		     (Select s.salle_id From SalleSecurisee s Where s.salle_name = 'bunker')
	     AND u.user_id =
		     (Select u.user_id From User u  Where u.user_name = 'toto');

Avec des jointures :

Code :

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

1
2
3
4
5
6
 
Select * From User u
	     INNER JOIN UserSalleSecurisee uss ON u.user_id = uss.user_id
	     INNER JOIN SalleSecurisee s ON s.salle_id = uss.salle_id
	     WHERE u.user_name = 'toto' 
	     AND s.salle_name = 'bunker';

Dans ce cas l'utilisation d'une sous requête est elle plus adéquate/performante qu'une jointure ?

[punkoff]

....

Bonjour,

En SQL il y a dès fois plusieurs moyens pour arriver au même résultat.
Ces moyens vont être interprété différemment, ou non, par votre SGBD et ceci selon pas mal de critère différent.


Donc quand vous avez plusieurs syntaxes qui donnent la même solution, pour connaitre la plus optimale, il faut les tester une par une et voir les plans d’exécutions générés.

Bien sur avec un peu plus d'expérience sur votre SGBD vous ne ferrez ce test que peu souvent.

[dehorter olivier]

CinePhil a donné la réponse

de toute façon la requête 1 va générer une erreur s'il y a plusieurs "TOTO" (d'où la requête avec le INproposé par StringBuilder).

Il y a même moyen de vérifier par vous même avec les statistiques d’exécution qui sont peut être fournies

[CinePhil]

Précisons quand même que la différence de performance ne se fera sentir qu'à partir d'un certain volume de données à traiter mais d'une manière générale, la jointure est plus performante car c'est l'opération la plus optimisée dans un SGBD.

Au passage, il faut que les colonnes figurant dans les conditions de jointures soient indexées sinon vous risquez de mal interprêter les résultats de vos tests.
Indexez aussi les colonnes interrogées dans la clause WHERE.

D'une manière générale toujours, remplacez ce genre de WHERE par une jointure !

Code :

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

1
2
WHERE uss.salle_id = 
		     (SELECT s.salle_id

[remdel59]

D'accord très bien !

Merci en tout cas à tous pour votre disponibilité !

Je passe le topic en résolu.