Bonsoir,

Je viens de lire la requête d'affichage des topics du forum issue du tutoriel à la page suivante http://www.siteduzero.com/tutoriel-3-9 [...] -d-index.html

SELECT cat_id, cat_nom, 
forum_forum.forum_id, forum_name, forum_desc, forum_post, forum_topic, auth_view, forum_topic.topic_id,  forum_topic.topic_post, post_id, post_time, post_createur, membre_pseudo, 
membre_id 
FROM forum_categorie
LEFT JOIN forum_forum ON forum_categorie.cat_id = forum_forum.forum_cat_id
LEFT JOIN forum_post ON forum_post.post_id = forum_forum.forum_last_post_id
LEFT JOIN forum_topic ON forum_topic.topic_id = forum_post.topic_id
LEFT JOIN forum_membres ON forum_membres.membre_id = forum_post.post_createur
ORDER BY cat_ordre, forum_ordre DESC

Et ma question est : cette requête n'est-elle pas super-mega-lourde ? Du point de vu où si il y'a 200.000 messages, elle affichera 200.000 lignes si j'ai bien compris ?
Parce-que je travaille sur un forum qui atteindra ce nombre important de messages et je cherche la requête la plus rapide possible.

Merci de vos éclairages.

Non si les colonnes correspondant à tes clés étrangères sont indexées correctement. Par contre ça serait très étonnant que tout ces LEFT soient nécessaires.

Tracker.

200.000 messages, ce n'est pas grand chose je t'assure

Après c'est sûr qu'un petit "LIMIT x OFFSET y" ou, mieux, un petit "WHERE RANK() BETWEEN x AND y" permettra d'améliorer au moins le temps de transfert des données

Citation : Tracker

Non si les colonnes correspondant à tes clés étrangères sont indexées correctement. Par contre ça serait très étonnant que tout ces LEFT soient nécessaires.

Tracker.

Je comprends pas, qu'est-ce que tu appelles "clés étrangères sont indexées correctement" ? Les LEFT permettent d'obtenir des informations sur toutes les tables de la requêtes, même ceux qui n'aboutissent pas à la jointure finale.

Citation : Shepard

200.000 messages, ce n'est pas grand chose je t'assure

Après c'est sûr qu'un petit "LIMIT x OFFSET y" ou, mieux, un petit "WHERE RANK() BETWEEN x AND y" permettra d'améliorer au moins le temps de transfert des données

Oui mais si on fait un LIMIT, on peut ne plus avoir l'info qu'on cherche (par exemple le dernier message du forum 3 du sujet 15) ?
Et je ne comprends pas non plus en quoi RANK peut changer le temps de transfert.

Donc d'après vous, c'est pas génant pour mysql de rapatrier le contenu de 200.000 messages (voir 10 fois plus) en une requête ?
Ne vaut-il pas mieux faire des requêtes imbriquées (3 niveaux d'imbrication) dans cette requête pour ne sélectionner que les quelques infos que l'on veut, ou cela prends-il plus de temps de que rapatrier tous les messages ?

Merci de votre intérêt.

Citation : FluidBlow

[...] Je comprends pas, qu'est-ce que tu appelles "clés étrangères sont indexées correctement" ?>

Dans une relation, pour schematiser deux tables sont mises en correspondance par au moins deux colonnes.
Dans ton exemple forum_membres et forum_post font référence l'une à l'autre par:
- membre_id dans forum_membres qui est clé primaire
- post_createur dans forum_post qui du coup est clé étrangère.

Sur des moteurs de stockage comme InnoDB, XtraDB et dans la quasi totalité des sgdb, un mécanisme (contrainte de clé étrangères) permet de GARANTIR que ces colonnes ne contiennent pas d'informations incohérentes.

En MySQL/MyISAM, qui est le moteur de stockage majoritairement utilisé (damned), ce mécanisme n'existe pas. Tu utilises donc une colonne comme clé étrangère sans être obligé de fabriquer un index dessus, donc attention.

Citation : FluidBlow

Les LEFT permettent d'obtenir des informations sur toutes les tables de la requêtes, même ceux qui n'aboutissent pas à la jointure finale.

Les jointures permettent d'obtenir des informations croisant plusieurs tables. Les LEFT JOIN sont des jointures particulières permettant de récupérer tous les éléments de la table de gauche même si la relation de jointure ne peut être satisfaite pas la table de droite.

Concrètement dans ta requête tu récupères même:
- les categories sans forum
- les forums sans post
- les posts sans topic (cohérent ? non)
- les posts sans membre (cohérent ? non)

Bref à toi de voir, mais un LEFT join est bien plus gourmand qu'un INNER JOIN, pas la peine de s'en servir sans but précis.

Citation : FluidBlow

Donc d'après vous, c'est pas génant pour mysql de rapatrier le contenu de 200.000 messages (voir 10 fois plus) en une requête ?

Pourquoi mysql rapatrierait 200.000 posts ?? tu comptes les afficher
Au pire avec de mauvais indexes il peut être ammené à tous les parcourir, mais de là à les rapatrier...

Tracker.

Merci pour tes informations, mais donc pour les LEFT JOIN, c'est bien ce qu'il faut, (moi en tout cas) j'ai besoin d'avoir les catégories même si personne n'a posté dedans.

Et normalement il n'y aura pas de problèmes de clé étrangère.

Et je dis rapatrier car quand on fait par exemple un

<?php echo print_r($mysqlFetch); ?>

et bien on vois bien le contenu de toutes les lignes, c'est donc bien que Mysql a été les chercher non ?

Merci pour ton aide.

il est clair que 4 jointure commence a etre beaucoup mais comme l'a dit tracker, si c'est bien fait cela passera.
Par contre, je pense en effet que toutes les jointure ne sont pas obligatoire, ou alors qu'il faut laisser tomber la 3nf, et revenir au mcd pour eviter autant de jointure

Dans un modèle bien analysé, beaucoup d'entités émergent donc évidemment faut des jointures. Par contre FluidBlow, un post sans topic ou sans membre c'est plutôt improbable... donc au moins deux jointures gauches doivent sauter (et ton ordre est à remanier).

Tracker.

Bon merci pour les infos; Je ferais plusieurs tests avec différentes requêtes comme ça je verrais bien ce que ça dit au niveau performance. Je vous tiendrais au courant.