8791 sujets

Développement web côté serveur, CMS

bonjour, je suis en train de coder un forum pour un de mes sites et je rencontre un probleme sur le principe du "up". en gros je veux ordonner les sujet en fonction de la date du dernier post. le probleme viens selon moins de mon manque de connaissance des jointure sql ou alors d'un défaut de conception de mon forum. pouvez vous m'aider ?

voici ma requête actuelle qui liste bien les sujets du forum sélectionné mais pas selon la date du dernier post :

 $reponse_sujets = mysql_query("SELECT cbo_forums_topics.id_topic, cbo_forums_topics.titre, cbo_membres.nom, cbo_membres.prenom, cbo_forums_topics.id_user FROM cbo_forums_topics, cbo_membres WHERE id_f=".$f." AND cbo_forums_topics.id_user=cbo_membres.id ORDER by date Desc LIMIT $premierMPAafficher , $nb_sujets_par_pages");


mon forum utilise 4 tables : une pour les catégorie de forum, une pour les forums, une pour les sujet et une pour les messages.

Structure de la table `cbo_forums_categories`

CREATE TABLE IF NOT EXISTS `cbo_forums_categories` (
  `id_categ_forum` int(255) NOT NULL auto_increment,
  `nom_categ` varchar(255) NOT NULL default '',
  PRIMARY KEY  (`id_categ_forum`)
) TYPE=MyISAM AUTO_INCREMENT=4 ;


Structure de la table `cbo_forums_forums`

CREATE TABLE IF NOT EXISTS `cbo_forums_forums` (
  `id_forum` int(255) NOT NULL auto_increment,
  `titre_forum` varchar(255) NOT NULL default '',
  `description_forum` longtext NOT NULL,
  `categ` varchar(255) NOT NULL default '',
  PRIMARY KEY  (`id_forum`)
) TYPE=MyISAM AUTO_INCREMENT=5 ;



Structure de la table `cbo_forums_messages`

CREATE TABLE IF NOT EXISTS `cbo_forums_messages` (
  `id_message` int(255) NOT NULL auto_increment,
  `id_t` varchar(255) NOT NULL default '',
  `contenu` longtext NOT NULL,
  `auteur` varchar(255) NOT NULL default '',
  `date` int(255) NOT NULL default '0',
  `ip` varchar(100) NOT NULL default '',
  PRIMARY KEY  (`id_message`)
) TYPE=MyISAM AUTO_INCREMENT=11 ;



Structure de la table `cbo_forums_topics`

CREATE TABLE IF NOT EXISTS `cbo_forums_topics` (
  `id_topic` int(255) NOT NULL auto_increment,
  `id_f` int(255) NOT NULL default '0',
  `titre` varchar(255) NOT NULL default '',
  `type` varchar(30) NOT NULL default '',
  `id_user` varchar(20) NOT NULL default '',
  `date` varchar(255) NOT NULL default '',
  `ip` varchar(100) NOT NULL default '',
  PRIMARY KEY  (`id_topic`)
) TYPE=MyISAM AUTO_INCREMENT=7 ;


merci par avance de votre aide.
Modifié par f-webconcept (27 Aug 2008 - 01:37)
Salut Fred,

le gros problème vient de la structure de tes tables. Tout d'abord il faut éviter d'utiliser des mots réservés MySQL (même si date est l'une des exceptions) et ensuite il faut utiliser le bon type de colonne.

Notamment un champs "date" devrait être de type DATETIME, DATE ou TIMESTAMP et les chiffres entre parenthèses (tu as mis 255 presque partout) n'ont pas la même signification pour chaque type : voir ce post.

A+


Edit: voir également ce post.
Modifié par Heyoan (26 Aug 2008 - 16:14)
slt, merci de ta réponse, pour ce qui es de ma structure de mes tables ok je vais faire les corrections. mais cela ne me di pas comment utiliser la date du dernier post du topics pour classer les topics... je pense qu'il y a une histoire de jointure mais voila je ne maitrise pas très bien les jointure ... j'aurai donc aimé donc quelques conseils sur le sujet...
f-webconcept a écrit :
mais cela ne me di pas comment utiliser la date du dernier post du topics pour classer les topics...
Si : en mettant un vrai type date (à priori datetime dans ton cas) le ORDER BY date_topic DESC va fonctionner. Smiley cligne
wé mais ça , ça marche déjà moi je veux utiliser la donnée : cbo_forums_messages.date et non pas cbo_forums_topics.date, c'est la que les jointure entre en jeux... sauf qu'il faut que je prenne la valeur la plus grande de cbo_forums_messages.date ou cbo_forums_topics.id_topic=cbo_forums_messages.id_t

je m'était peut être mal exprimé.
f-webconcept a écrit :

je m'était peut être mal exprimé.
Oui... peut-être ! Smiley langue

Alors en supposant que tu aies réglé le problème des types et que tu aies maintenant un champ date_msg de type DATETIME il faudrait également corriger les jointures qui, dans un monde parfait (et donc normalisé), se font sur des champs de même type et le plus souvent sur des identifiants.

Donc remplacer :
cbo_forums_forums.categ par cbo_forums_forums.id_c (INT)
et
cbo_forums_messages.id_t (VARCHAR) par cbo_forums_messages.id_t (INT)

Ensuite ça devrait donner quelque chose comme :
$reponse_sujets = mysql_query("SELECT T.id_topic, T.titre, MBR.nom, MBR.prenom, T.id_user FROM cbo_forums_topics AS T, cbo_membres AS MBR, cbo_forums_messages AS MSG WHERE id_f = ".$f." AND T.id_user = MBR.id AND T.id_topic = MSG.id_t ORDER by MSG.date_msg Desc LIMIT $premierMPAafficher , $nb_sujets_par_pages");
Modérateur
Bonjour,

Pour ma part, je te suggère de créer un champ DernierMessageDateHeure dans la table de tes sujets qui servirait à stocker la date du dernier message du sujet. À chaque insertion ou suppression d'un message dans le sujet, tu met à jour ce champ. Le tri des sujets s'effectue sur ce champ, au lieu de passer par des jointures.

L'avantage est que cela demande beaucoup moins de ressources pour le serveur car il n'a pas besoin, à chaque fois qu'il affiche les sujets, d'aller chercher dans la table des messages pour les classer en ordre.

C'est la solution que j'ai opté pour le forum que j'ai développé, et cela semble également le cas pour les autres applications de forum que l'on peut retrouver sur le marché.

Cette solution est aussi valable pour le ID du dernier message, le ID et le nom de l'auteur du dernier message, le nombre de messages du sujet, etc...

Pour choisir un bon schéma de base de données, tu peux t'inspirer des applications de forum OpenSource.
merci beaucoup de ton aide Heyoan c'est justement ce que je cherchait a faire.

@Tony Monast : c'etait mon idée que j'avais dans le cas ou je trouverai pas d'aide.. mais comme j'avais discuté ac un type sur un forum de programmation et qu'il m'avait di de ne pas stocker des données redondantes..je l'avais pris au mot...

du coup je ne sais plus quelle option choisir...
Modifié par f-webconcept (26 Aug 2008 - 22:01)
Modérateur
Oui, en général, il est recommandé d'éviter de stocker les données redondantes, mais jusqu'à un certain point. Si tu examine la majorité des applications de forum opensource ou commerciales, il y a certaines données qui sont stockées de façon redondantes pour des questions de performances, dont le nombre de sujets et de messages, les données du dernier message (id, dateheure, auteurid, auteurnom, etc...).

Si tu utilise déjà au maximum les ID des enregistrements et les relations dans la base de données, tu peux te permettre d'appliquer ma solution pour ce cas particulier. Puis je tiens à préciser que ce n'est pas pour contrer une méconnaissance des jointures, mais bien pour une question de performances et de ressources utilisées.
Modifié par Tony Monast (26 Aug 2008 - 22:14)
f-webconcept a écrit :

mais comme j'avais discuté ac un type sur un forum de programmation et qu'il m'avait di de ne pas stocker des données redondantes..je l'avais pris au mot...

Et bien dans ce cas bien précis je serais également de l'avis de Tony : c'est vrai qu'en général il ne faut jamais dupliquer ses données... sauf dans de très rares exceptions ! Smiley cligne

Typiquement dans le cadre d'une optimisation des ressources car pour 1 update de la table topics à rajouter au moment de la création d'un message tu évites une "grosse" jointure à chaque affichage du forum.

Edit: grilled !
Modifié par Heyoan (26 Aug 2008 - 22:14)