Discussion :

[Just]

Bonjour,

Ma philosophie me pousse à croire que la meilleure façon de faire du requétage SQL est de concentrer le maximum de demande en une seule requête.
Et donc, pour cela, de faire des jointures multiples.

Mais est-ce que dans certains cas de figure, notamment dans le cas ou les tables jointes ne sont pas hiérarchisé en un seul sens (parent, enfant/parent, enfant/parent, enfant), n'a t'on pas bénéfice à faire plusieurs requêtes distinctes (d'un point de vue "performances")?

Exemple:
On a des "groupes de sites" qui contiennent des "sites", qui contiennent des "groupes de pages", qui contiennent des "pages". Chacune de ces entités est aussi lié à une table "information".
On veux récupérer l'ensemble des données, cad les enregistrement de la table "information" pour chaque entité, ainsi que les enregistrement de chaque entité elle même.
Doit-on faire une seule requête?
Ou de multiple, ça d'abord chercher les enregistrements pour chaques entité (avec des jointures) puis, dans des requêtes séparé, les enregistrements de la table "information" correspondant à chaque entité?

J'ai essayé de faire un exemple simpliste mais... ce n'est pas simple .
Voyons voir ce que vous en pensez .

[ced]

Bonjour,

Si il n'y a pas de sous-requêtes (qui dégradent les performances), je privilégierais une seule grosse requête, ce qui limite les accès multiples au serveur pour X requêtes...

ced

[Just]

Merci Ced pour ta réponse.

En faites j'aurais tendance à dire qu'il faut vraiment pour chaque requête se poser la question.
En effet cela dépend des jointures effectué, du volume récupéré, etc.

Il n'y a don pas en mon sens de réponse ferme à ma question.

Tout est question d'optimisation tant en matière de requête que d'indexage de la BDD (par exemple).