1 ou 2 tables pour les messages ??
 
c.a.d une table message avec titre et une avec les reponses
 
ou bien 1 seule table avec tt les messages et un champ 'title' qui peux etre NULL
 
En fait , je suis en train de creer un forum similaire en plus light , j'ai reussi a travailler avec une seule table , mais un probleme se pose pour le tri des messages par date de la derniere reponse...
 
si vous pouvez m'eclairer    
 
voila ma structure de table :
 

Il me semble qu'il a une table "topics" et une table "messages", enfin il est mieux placé que moi pour le dire

il veux rien dire sur son modèle de données, il garde tout pour lui

 
 
Salut, pour mon forum, j'ai mis deux tables, une pour les messages (avec titre et données du message) et une autre pour les réponses.
 
Il me semble que c'est une bonne solution comme j'ai fait, je n'ai aucun problème. Je te conseil de faire comme ça, il me semble que c'est plus simple et mieux ordonné dans la base

Je pense que Joce a créé deux tables en effet, parceque tout dans une seule, c'est un peu pourri
 
Sinon, pour ta requête bon courrage, je vois ce que tu veux faire, et t'es obligé de le faire en deux fois :
-> Une fois pour récupérer le premier post, et une fois pour récupérer le topic associé.
 
PS: Quand je dis en 2 fois, ça veuxpas forcément dire en deux requête, en une seule requête avec sous-requête y'a moyen. Pas envie de me faire chier à l'écrire par contre, j'ai réfléchit 30 secondes dessus et j'ai pas eu le courrage

J'avais fait ça aussi à un moment, mais le message du topic est ni plus ni moins qu'une réponse en fait.
C'est plus facile à gérer donc avec le message du post dans la même table que les réponses.

 
Je me suis mal exprimé, ce que j'appelle message et un topic en fait. Dans la table topic, il n'a que des données du topic (titre, date, dernier poste,...)

Ha ok
 
Une table topic avec que le titre quoi

 
c bon j'ai kan meme reussi avec mon archi. à une table, meme si c un peu degeu
 
mais j'ai pas envie de refaire une architecture basé sur une table  

t'es bien parti pour faire un forum de merde alors

Moi, je vous conseille la chose suivante :
 
Une table pour les sujets (id sujet et texte du sujet)
Une table pour les index de réponses (id réponse, id sujets parent et id texte de réponse)
Une table pour le texte des réponses (id et texte)
 
 
 

la table pour le texte des reponses n'a a mon avis d'interet que si tu stockes autre chose dans la table index de reponses et que tu souhaites la mettre en format statique.
Parce que a part ca separer index et texte c con vu que de toute facon t'auras un texte pour chaque id reponse.

 
Bien sur, mais la table "réponse" contient tous les champs de controle : id sujet, date, edit, auteur, ip...
 
La table "texte de réponse", elle, ne contient que trois champs : id, id message, texte.
 
ça permet plusieurs choses :
Déjà, de séparer en deux le volume total d'une table unique, ce qui pour des tables de plusieurs millions d'enreg, est interessant.
 
Ensuite, ça permet de faciliter les rechercher en plein texte.
La table "texte des réponse" n'est pas sur-indexée, elle n'a que son index de champs clé.
 
La table "réponse", elle, est multi-indéxé (id primaire, id sujet,  et date).
 
Une recherche texte sur une telle table serait trop couteuse.

de ton point de vu on est d'accord, et t'en profite pour foutre la deuxieme table en statique pour accelerer les acces aux index
ceci dit, ca te fait faire une jointure en plus, et donc faut faire un seek pour la table reponse et ensuite pour la table texte reponse.
Si comme moi tu n'utilises pas la table texte des reponses pour le moteur, tu n'as a mon avis pas interet a splitter la table en deux.

 
     
 
non c bon j'ai remodelisé la parties message en 2 tables

 
ça serait à tester, en effet.
Et puis ça depend fortement de la database utilisée.
 
Sur Mysql, j'en sais rien.
Sur SQL serveur, sur de grosses table, le gain est effectif.
Sur Oracle, aucun interet, les perfs de cette DB ne sont pas dependante du volume des tables.
 
 
 
 

pour mysql non plus, vu que l'index statique se contente de faire taille du champ * offset pour trouver la position de l'entree dans le fichier de donnee

 
si j'ai le temps de tester , j'aimerais bien faire une version du forum qui taperait sur la meme base mais sous SQL Server , je pourrais enfin profiter des contraintes d'integrité
 
ca serait aussi marrant de voir en perf ce ke ca donne
 

Mais dis moi, tu n'as pas prévu la possibilité d'avoir plusieurs forum    
 

Sinon, en SQL serveur, c'est à mon avis bien plus rapide, mais ça nécéssite un serveur plus puissant (je sais, ça parait con)

 
   plusieurs categories mais pas plusieurs forum

 
je vois.

Sinon, là :  http://80.65.230.180/forum/ tu as mon forum (mais trés loin d'etre fini) en ASP.NET / SQL serveur.
 
Pour info, j'ai plus de 15 tables.

 
putain, au niveau perf ca tient la route meme avec de l' ADSL !!  
 
.NET      
 

 
regarde celui la  
 
http://raph93.dyndns.org/forum/

 
Heu... non, là, question perfs, c'est minable (80 millisecondes de génération de page).
 
Le serveur n'est même pas digne d'un PC bureatique Pentium II    
 
Mais sur des plateformes plus grosses, on tombe à 8 milliseconde par page, requète SQL comprise.
 
Sinon, le .NET  

 
Pas mal aussi !
Mais comme pour le mien, y'a encore du taf  

 
C'est quoi le rapport ?

 
ben il heberge la connexion chez lui , la bande passante n'est pas la meme que s'il etait chez un hebergeur avec une LS 2mbits  

comment ont recupere le temps de generation des pages ??
 
jvoudrais bien l'implementer sur mon forum

oui, et ? le rapport avec la génération de la page ?

 
Oui merci, j'avais pigé ça, mais je vois pas trop le rapport .NET qui tient la route "même en ADSL"... À priori le système dépend pas de la connexion
 
edit: grilled

 
aucun  

tu sais que MySQL a aussi les contraintes d'integrite

SQL Server se fait torcher par MySQL a config equivalente

 
t payé combien pour leur faire la promo ???

c'est pas de la promo c'est de l'information vu qu'apparement t'as pas au courant

 
je sais bien qu'en perf. il est pas mal , et vraiment moins lourd que SQL Server, mais peut-on vraiment appellé ca un SGBD  

Ba oui, qu'est ce qui lui manque (a part les views, les triggers et le PL/SQL qui sont en cours d'implementation) ?

 
de toute facon , c'est gratuit alors jpeux pas me plaindre