Salut, les requêtes imbriquées et les jointures ne sont pas des fantaisies...
Elles tirent parti des index de table, pour peu qu'on en ait mis, et sont très rapides. Certainement plus rapides que 3 requêtes distinctes, qui requièrent 3 échanges serveur web / serveur base de données.
De plus, avec ta méthode, chacune de tes requêtes parcoure TOUS les enregistrements des tes 3 tables.
Supposons que tu aies 1000 membres, 5 classes et 10 guildes, ça te fait parcourir toutes les classes et toutes les guildes pour chaque membre.
Avec des jointures et des index ( qui manquent dans ton script SQL pour les champs exe_membres.membre_guilde_id et exe_membres.membre_classe_id), tu aurais parcouru une classe et une guilde pour chaque membre. Deux jointures dans une requête en plus, c'est très light...
A titre d'exemple, un pote a fait une requête avec 6 jointures et 2 requêtes imbriquées. Il manquait des index et certaines conditions de jointures étaient mal écrites. Résultat : ~ 1 minute d'exécution. Après optimisations => 1 seconde.
Elles tirent parti des index de table, pour peu qu'on en ait mis, et sont très rapides. Certainement plus rapides que 3 requêtes distinctes, qui requièrent 3 échanges serveur web / serveur base de données.
De plus, avec ta méthode, chacune de tes requêtes parcoure TOUS les enregistrements des tes 3 tables.
Supposons que tu aies 1000 membres, 5 classes et 10 guildes, ça te fait parcourir toutes les classes et toutes les guildes pour chaque membre.
Avec des jointures et des index ( qui manquent dans ton script SQL pour les champs exe_membres.membre_guilde_id et exe_membres.membre_classe_id), tu aurais parcouru une classe et une guilde pour chaque membre. Deux jointures dans une requête en plus, c'est très light...
A titre d'exemple, un pote a fait une requête avec 6 jointures et 2 requêtes imbriquées. Il manquait des index et certaines conditions de jointures étaient mal écrites. Résultat : ~ 1 minute d'exécution. Après optimisations => 1 seconde.