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.
la communauté d'entraide francophone dédiée au PHP
un forum de base - combien de tables?
Administrateur PHPfrance |
3088 Messages
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.
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 :
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:
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.
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 : Tout sélectionner
+---------------------------------------------------------+
| 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.. |
+--------+---------------+--------------------------------+La requête SQL à envoyer pour extraire un message et ses réponses pourrait ressembler à ceci:
Code : Tout sélectionner
SELECT `msg_texte`
FROM `messages`
WHERE `msg_id` = 1
OR `msg_parent_id` = 1
ORDER BY `msg_id`;Codez en pensant que celui qui maintiendra votre code est un psychopathe qui connait votre adresse 
Invité
Invité n'ayant pas de compte PHPfrance
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?
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?
tu pourrai par exemple structurer ton forum.
Code : Tout sélectionner
Forum Divers
SousForum : BlaBla
SousForum : Presentez vous
Forum Programmation :
SousForum : PHP
SousForum : SQL
etc.
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é....quand je lui ai montré la base de donnée, il m'a dit que c'était pas assez poussé
À 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.
Codez en pensant que celui qui maintiendra votre code est un psychopathe qui connait votre adresse
Invité
Invité n'ayant pas de compte PHPfrance
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.
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.
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 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
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....faire une table sujet et une table reponse mais tres franchement je ne vois pas l'interet
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.
Codez en pensant que celui qui maintiendra votre code est un psychopathe qui connait votre adresse
Administrateur PHPfrance |
3088 Messages
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.
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.