Je ne trouve pas que séparer topics et posts soit plus "complexe", au contraire je trouve cela des plus logique et beaucoup plus simple. Les posts sont des documents, les topics sont des collections de documents, essayer de fusionner ces deux notions ne me semble pas cohérent.

Pire encore, d'un point de vue technique cela devient vite un cauchemar. Par exemple, il faut s'assurer qu'un message répond bien à un message "racine" (c-à-d un messages dont msg_parent_id = 0) sinon on crée une hiérarchie des messages et on change du tout au tout en ce qui concerne la requête nécessaire pour obtenir la liste des messages d'un topic. Autre point, dans la requête SQL citée plus haut, beaucoup de serveurs SQL ne pourront pas optimiser l'usage des indexes correctement parce qu'on deux conditions sur deux colonnes différentes (msg_id et msg_parent_id) qui ne sont pas liées.

Tout ça pour dire que créer beaucoup de tables n'est pas un signe de complexité, il faut avant-tout regarder les requêtes nécessaires pour extraire les données de ces tables.

il sedrait interessant de voir comment ont été optimisé
c'est peut ca aussi qui n'est pas assez poussé

[quote="jeff"]...faire une table sujet et une table reponse mais tres franchement je ne vois pas l'interet[/quote]
Mon avis : non seulement ça n'a aucun intérêt, mais c'est également incohérent. Quand on modélise, on identifie les éléments pour définir les entités distinctes et les propriétés de ces entités: on fait pas des doublons juste pour que "ça ait l'air professionnel", ça n'est ni professionnel ni sérieux.

On ne peut pas parler d'un forum "de base" si on ne fait pas en sorte de simplifier autant que faire se peut la structure. Développer n'est pas une fin en soi et il m'apparaît comme aberrant de vouloir absolument monter un système tordu.

Je conçois qu'un formateur donne la préférence à un projet présentant un minimum de complexité, mais dans ce cas, on ne rend pas complexe un problème basique, on cherche un projet qui soit un peu plus exigeant en terme de fonctionnalités, demandant de ce fait une modélisation plus complexe. Donc si le modèle suggéré pour un forum de base est insatisfaisant pour le formateur, alors ajoute des fonctionalités à ton forum de façon à justifier l'ajout de tables permettant d'intégrer ces autres points, mais ne découpe pas une table en deux simplement pour que ça fasse plus de tables.

salut
tu peut faire un peut differement, l'esprit reste le meme, le seul gaine est l'affichage des sujets

tu separe la table de que t'a donnée cyrano en 2,
une tableou tu trouve l'emplacement d'un sujet
et la deuxieme ou il y a le corps de celui-ci
ci tu gere que 2 niveaux tu peut meme faire une table sujet et une table reponse mais tres franchement je ne vois pas l'interet

tu connais pas ce prof toi...
c pas le genre à écouter les arguments de ses élèves pour le convaincre.
quoi que tu lui dises il est convaincu qu'il a raison. j'ai essayé je t'assure mais quand je te dis qu'il est un peu relou c'est pas façon de parler. un pur chieur. me suis bien embrouillé avec lui la dernière fois, j'ai pas envie que ça se reproduise.
donc voila bon je vais rajouter la table membre je pense que ça ira (c'est assez logique dans le sens où si elle n'existait pas, il y aurait redondance des pseudos et mails dans la table des messages.
merci quand meme.

[quote="Anonymous"]...quand je lui ai montré la base de donnée, il m'a dit que c'était pas assez poussé[/quote]
Développement poussé ne signifie pas obligatoirement "Usine à gaz" : on est pas obligé de concevoir une base en multipliant inutilement les tables simplement pour faire plaisir. Il faut commencer par modéliser le tout, définir de quoi tu as besoin, quelles sont les Entités/propriétés pour créer un MPD cohérent. Si on parle d'un forum basique, alors ce que je t'ai montré est suffisant et surtout efficace. Or ce qu'on cherche avant tout lorsqu'on élabore un projet, c'est l'efficacité.

À toi de développer les arguments pour justement défendre le fait que pour un projet de base tu n'as pas besoin d'avoir 50 tables. Une base de données de forum comme celle de phpBB par exemple est d'un tout autre calibre, mais c'est parce que le nombre des fonctionnalités offertes par ce forum sont autrement plus nombreuses qu'un forum de base.

tu pourrai par exemple structurer ton forum.
[code]
Forum Divers
SousForum : BlaBla
SousForum : Presentez vous
Forum Programmation :
SousForum : PHP
SousForum : SQL
etc.
[/code]

oui mais non...
en fait c'est un projet pour un prof de php assez relou.
il voulait un forum basique mais quand je lui ai montré la base de donnée, il m'a dit que c'était pas assez poussé, qu'il fallait qu'elle soit mieux structurée (sans rajouter de champ supplémentaire) en créant plus de tables.
mais à part les tables membres, messages et reponse_message, je vois pas ce que je peux faire de plus.
vous avez une idée?

Dans un genre beaucoup plus basique mais toujours fonctionnel, il y a mon forum, disponible en téléchargement libre sur ma page perso. Ce forum a prèsque trois ans, mais il est toujours fonctionnel.

Ceci dit, tu pourrais ne faire qu'une seule table "messages" et avoir un champ "msg_parent_id" qui serait en quelque sorte une clé étrangère à l'intérieur de la table même puisque ça servirait à mettre la clé primaire du message auquel la ligne correspond. Exemple sommaire :
[code]+---------------------------------------------------------+
| messages |
+--------+---------------+--------------------------------+
| msg_id | msg_parent_id | msg_texte |
+--------+---------------+--------------------------------+
| 1 | 0 | un texte de premier message. |
| 2 | 1 | Une réponse au premier message |
| 3 | 0 | un autre message sans parent.. |
+--------+---------------+--------------------------------+[/code]
Observe le schéma : Il y a trois messages dans la table, deux avec un identifiant de parent avec la valeur "0" et un avec la valeur "1". Ça veut dire que la seconde ligne est une réponse au message dont la clé primaire est "1" : tu peux classer les réponses dans l'ordre par la clé primaire.

La requête SQL à envoyer pour extraire un message et ses réponses pourrait ressembler à ceci:
[code]SELECT `msg_texte`
FROM `messages`
WHERE `msg_id` = 1
OR `msg_parent_id` = 1
ORDER BY `msg_id`;[/code]
Cette requête va sortir les deux premières lignes dans l'ordre, le message d'origine puis les réponses. Pour convertir en PH' il te suffira de remplacer le "1" par une variable correspondant à la clé primaire du message que tu veux voir. Quant à afficher la liste des messages, tu peux le faire en faisant une requête ne cherchant que les messages dont le champ msg_parent_id a une valeur "0" et tu n'auras que les messages d'origine sans les réponses.

Si tu veux te faire une idée des tables nécessaires tu peux télécharger phpBB et Phorum, ils possèdent tous deux une base de données assez classique.

Bonsoir,
je viens de développer un forum très basique en PHP avec les éléments suivants : id_message, pseudo, mail, titre, message et date.
J'ai créé 2 tables pour differencier les messages de reponses des messages principaux. Ces tables sont forum et reponse avec les memes champs dans chaque table mais dans reponse un champ supplémentaire : reponseA.
Bon je me doute bien que c'est pas optimisé mais bon, je débute.
J'imagine deja qu'il faut que je crée une table membre avec id, pseudo et mail.
Vous pourriez me conseiller un peu?
Merci.