Listing de sujet par date sujet / commentaire

[Siol]

Bonjour,

Je suis actuellement entrain de programmer un forum, il dispose de la table "sujets" ainsi que la table "reponses" disposant tout deux d'un champ "date".

Je voudrais pouvoir listé les sujets, par "date" de la table "sujets" et si il y a des "reponses", que le sujet soit listé par la "date" de la réponse.

Je ne voi pas vraiment comment faire tout en gardant les même tables et champs.

Pour l'instant les sujet sont listé seulement par leur "date" sans relation avec les "reponses".

 $selectsujet = "SELECT * FROM sujets ORDER BY date DESC";

Merci.

Cordialement.

Modifié 17 Mai 2006 par Siol

[captain_torche]

Personnellement, pour pallier à ce souci, j'enregistrerais le premier message dans la table réponses, la table sujets ne contenant que le titre du message, ainsi que les liaisons dans les différents forums, et sous-forums.

Ainsi, la question sera juste considérée comme le premier message, et tu n'auras plus de souci pour les organiser par date.

[TheRec]

Bonsoir,

Dans ta table sujet, tiens un compte des réponses...cela épargnera des ressources lorsque tu feras l'affichage de la liste de sujet (il faut penser que ce nombre devra être affichés à plusieurs endroits et souvent). C'est un conseil à part.

Concernant ton problème de tri, il est souvent résolu en ajoutant un champs à la table sujet "last_post_at" (dernier_message_a) qui correspond au dernier message...tenu à jour lorsque quelqu'un ajoute un message à un sujet...ainsi cela évite des requête superflues. Cela te permet aussi de distinguer les sujest ayant des réponses ou non...donc il faut autoriser le "NULL" et s'assurer que lorsque le dernier message d'un sujet est supprimé, le "NULL" est bien restauré.

Ensuite tu pourras trier tes sujets par date et par date de dernier message sans avoir à parcourir toute la table des réponses...

Cela peut paraître comme des entorses à la normalisation de ton schéma de base de données, mais cela a un impacte non-négligeable lors de la consultation massive (typiquement, un forum correspond à ce cas).

Tu peux regarder le schéma de plusieurs systèmes de forum, phpBB, PunBB, ... cest une bonne source "dinspiration"

[Siol]

Oui merci pour vos réponses.

Sa me chagrine un peu d'ajouter un champ dans une table alors qu'une autre table contient les infos :/

Si quelqu'un trouve une requete pour calculer sa.

[TheRec]

Dans ce cas-là, si tu ne te soucies pas des ressources impliquées, cela fera une requête par affichage pour une information qui est "statique" (dans le sens ou elle ne peut changer que par l'intermédiaire de ton forum...elle ne dépend pas d'un autre système) voici ce que tu peux faire :

SELECT sujets.*, MAX(reponses.date_message) AS date_dernier_message FROM sujets LEFT OUTER JOIN reponses ON sujets.idsujet = reponses.idsujet GROUP BY reponses.idsujet ORDER BY date_dernier_message DESC

Mais sur une table avec des plusieurs milliers (voire centaines de milliers) de message la requête sera lente...peut importe l'optimisation et les INDEX...la table doit être analysée dans son entier pour retrouver la date avec la fonction "MAX"...franchement, un champ règle ce problème...et c'est un usage courant et logique...la normalisation est respectée.

[Siol]

Merci pour la réponse. Je galere a le faire marcher depuis tout a l'haure.

Sa ne m'affiche que 2 entrées.

Voila le code :

SELECT forums_topics.*, MAX(forums_comments.time) AS time_comment FROM forums_topics LEFT OUTER JOIN forums_comments ON forums_topics.id = forums_comments.topic GROUP BY forums_comments.topic ORDER BY time_comment

Sachant qu'il y a les tables :

forums_topics (avec id / time)

et

forums_comments (avec id / topic / time)

Je voi pas ou ai la faille je cherche a décortiquer tout sa.

Modifié 17 Mai 2006 par Siol

[TheRec]

Autant pour moi... cette requête ne fonctionne pas, car dès le premier élément qui n'a pas pû faire le groupement (GROUP BY) MySQL semble arrêter la collecte des résultats...je n'ai pourant pas lu de tel comportement dans le manuel...mais apparemment ce n'est pas le bonne méthode...

Si personne d'autre n'a de solution, à mon avis tu vas pouvoir utiliser la solution la plus raisonnable... ajouter ces champs qui sont tout à fait justifiés.

[Siol]

Hum dommage. C'est possible pourtant non ?

[TheRec]

J'ai de gros doutes... j'ai émis une hypothèse en te donnant cette requête, c'est comme "j'aurais voulu que MySQL fonctionne"...apparemment ce n'est pas le cas, et je t'avoue que je n'avais jamais testé le GROUP BY en provenance d'une table externe à la requête initiale...tout simplement parce que comme je te l'ai dit cela nécessiterait au moteur de MySQL d'examiner toute une table pour en trouver son maximum après en avoir déjà recherché tous les éléments pour réaliser le GROUP BY...en suite il fait ceci pour chaque sujet de ta table "forums_topics" ...

Te représentes-tu le nombre de "requêtes" internes que cela implique ? Non ? Au moins 3^n ... ou n est le nombre de sujets dans ton cas...

Si quelqu'un à une solution plus efficace que de stocker et mettre à jour un compteur dans la table des sujets, qu'il n'hésite pas à se manifester...en plus cette solution n'implique une mise à jour de ce compteur ou un champ avec la dernière modification, uniquement lorsqu'un message est ajouté, modifié ou supprimé...ce qui implique tout de même moins de requête que de calculer ceci à chaque fois qu'un sujet est affiché !

Et pour te convaincre...en une seule requête tu pourras compter l'entier de tes messages et sujet...alors qu'en stockant ces informations dans deux tables tu devrais faire 2 requêtes et effectuer la somme des deux résultats ensuite

[Siol]

Donc il me reste le choix :

1 : Faire un champ "Last post at" dans la table "Sujets"

Soi, ce que je prefererai :

2 : En fesant une seule table "Post" en incluant Sujets et Réponses. Mais comment gerer le listing des Sujets ?

Hum hum hum

[TheRec]

Bien que je t'indique que c'est la pratique la plus courante et la plus performante, tu ne souhaites pas opter pour cette option... je ne vois pas ce que tu penses apporter avec un forum qui consommera plus de ressources à l'affichage qu'à l'utilisation...enfin, libre à toi de programmer ce que tu veux, sur ce point je n'ai rien à dire

La séparation des sujets et réponses est importante du point de vu de la modélisation de la base de données. Si tu viens à mettre ces deux entités dans une seule table, tu vas passer ton de temps à chercher quels sont les sujets et quels sont les messages lorsque tu en auras besoin... alors qu'en séparant ces deux entités tu les distingues simplement...

Je ne peux pas vraiment t'aider plus si tu t'oriente vers la solution que tu "préfères" ... je ne souhaite pas te donner des conseils qui te mèneront de manière certaines à de mauvaises pratiques de programmation et de modélisation.

Si tu changes toutefois d'avis et que tu as encore d'autres questions sur la méthode que je te propose, je n'exclus pas la possibilité de répondre, si bien entendu j'en suis capable

[Portekoi]

Bonjour,

Perso, j'avais opté pour la première solution.

Un petit Update dans le champ 'lastpost' et le problème est réglé

Ajoute en plus l'id de la personne et sera parfait

Portekoi

[Siol]

C'est pas parfait tout sa il doit y avoir une alternative.

Si je le gere en flux xml ? (sa reduirai les requetes non ?)

Modifié 18 Mai 2006 par Siol

[Portekoi]

Tu sais, les principaux systèmes comme PHPBB ou autre utilisent se système. Pourquoi vouloir réinventer la roue?

Tu nous demande des solutions et c'est que l'on t'a donné.

Un flux XML? Oui pour faire compliter y a pas mieux.

A toi de voir.

[Siol]

dsl je suis un peu perfectionniste. J'ai de toute façon laisser tombé la version initiale.

Je me demande juste lequel choisir entre Flux xml ou Comme énoncé.

A savoir, lequel es le meilleur ?

[Portekoi]

Re,

Tout dépend du nombre de post par page et la fréquentation de ton site.

Si à chaque réponse, tu réécrires ton fichier XML, je ne suis pas certains de l'efficacité de cette solution.

Portekoi

[Siol]

Le forum es fait pour un gros trafic.

Que me conseilles-tu ?

[Spidetra]

Le forum es fait pour un gros trafic.

Que me conseilles-tu ?

<{POST_SNAPBACK}>

suit les conseils de Portekoi => db, 2 tables, champ pour compter

N'hésite pas a ajouter le champ qui compte le nb de post.

La mise à jour de ce champ peut même se faire par trigger sur les évenement On INSERT et On DELETE

Un peu de dénormalisation ne fait pas de mal de temps en temps.

[Siol]

Ok merci sa marche.

[TheRec]

C'est intéressant de devoir arriver à 18 messages alors qu'une réponse semblable se trouvait déjà au troisième message

Tout ça pour te dire que, oui c'est un forum, oui c'est fait pour discuter, mais plus sérieusement lorsqu'on te propose une solution fait l'effort de considérer celle-ci au delà de tes aprioris. Ce n'est pas parce que 2 autres personnes te confirment que c'est une solution correcte que tu dois opter pour cette solution, mais parce que c'est la manière la plus logique et efficace de gérer cela...

Rien ne nous force à répondre aux messages sur ce forum, mais pense bien qu'on ne va pas non plus passer notre journée à essayer de convaincre chaque utilisateur qu'on ne dit pas que des sottises...

Bref je ne souhaite pas te faire la morale, je désire simplement faire gagner du temps à chacun étant donné que les gens viennent ici pour s'entraider.

[Spidetra]

désolé TheRec, j'ai fait une erreur de pseudo dans mon précédent post.

En fait c'était à ton post auquel je faisais référence.

C'est vrai que le thread est tellement long , que je me suis planté. désolé !

Modifié 19 Mai 2006 par Spidetra

[TheRec]

Franchement, il n'y a pas de quoi s'excuser, je ne suis pas en manque de reconnaissance Spidetra Mais merci de l'avoir préciser... ce n'est pas le but de mon précédent message !