Reprise du message précédent :

 
t'as pas compris, num_message c'est la position du message dans le sujet et non dans la table.
 
par exemple t'as le message avec l'id 568 et comme c'est le premier message du topic, he bien num_message sera egal a 1, donc au lieu de faut limit 0,30 tu fera where num_message between 1 and 31 et tu mettre un index sur num_message.

Non vraiment dsl mais c'est toi qui n'as pas compris je crois :
L'interet d'une clef primaire sur deux champs erst justement ici regarde -> la clef primaire de message est id_sujet + id_message il ne peut y avoir qu'un seul message 1 pour l'id_sujet 1 et toi par dessus tu ve rajouter un champ num_message explique moi l'interet ? A part grossir la base bien sur
 
Exemple :
Primary key (id_sujet,id_message)
table_message
id_sujet  |  id_message
1             1
1             2
2             1
2             2
 
Donc ou vois tu l'interet d'un num reponse ?

 
Si j'ai bien compris Fabien, l'intérêt réside dans la suppression de la clause LIMIT.

absolument

Tres bien alors si vous faites cette requete avec ma structure :
 
SELECT post FROM `table_post`  
WHERE id_sujet = ".$sujet_en_cours."
AND id_message > ".($page_en_cours*$nb_post_par_page)."
AND id_message < ".(($page_en_cours*$nb_post_par_page)+$nb_post_par_page)."
 
Il est ou le LIMIT ?
 
J'ai l'impression que qq chose m'echape pour que personne ne me crois ... je sais pas expliquer moi ou mon raisonnerment est faux car je m'inquiete  

perso, je comprends

si tu prefere a la place de num_reponse, on peut mettre num_page, tu comprend mieux comme ca ?
t'as lu au moins les derniers messages de ce topic ? t'as pas compris qu'on essaye de chercher un moyen pour eviter le split pour les gros topic et avoir des temps de generation minimum quelque soit la page ?
et avec un numero de page,  ca nous evite d'utiliser la clause limit .
 
t'as compris maintenant ce que je voulais dire ?
 

Je pense avoir compris ce que tu veux oui ...
Mais peut tu me dire en quoi ma méthode est plus lente ?
C'est tout ce que je veux savoir moi ... car je n'utilise pas de LIMIT

mais donc ton truc, id_message, tu le remplit comment ?  

Quand tu post tu vois tu regarde le plus haut id_message du topic et tu l'incremente du 1 hop la tu vois pas la peine de s'enerver et meme pas la peine de faire un SELECT MAX tu le stock dans le topic carrement, et la tu pe generer des topic a la page voulue sans LIMIT et en gardant le choix du nombre de post par page
 
PS : plus de la moitie des dernier post ont été posté par rainbow_efreet je te remrcie de l'estime que tu me porte en me demandant si je les ai luent hum  

 
Ce système marche très bien pour les messages, mais pour les posts, ça tombe à l'eau (malheureusement) car les id tronque complètement la recherche sur la date.

Le fait est que j'ai du mal à comprendre ta distinction entre message et post, tu pourrait me l'expliquer, car en fait dans mes post je melange les deux mots car je sais que la plupart des developpeur de forum ici present parle de post et que moi je developpe a la franchouillarde et j'ai appelé ça message

 
hum autant pour moi, c'est moi qui me suis mal exprimé    
 
Pour les topics (sujets   ), cela pose un gros problème ce système car la pagination ne peux pas être fixe. Sinon, pour les messages, ça fonctionne très très bien.

mmm on peut voir cela comme une sorte de hierarchie et encore faire une clé primaire composé de id_forum,id_sujet car le forum 1 n'aura qu'un seul sujet 1
Donc
 
Primary Key(id_forum,id_sujet)
Table_Sujet
id_forum     id_sujet
1            1
1            2
1            3
2            1
etc
et avec le meme genre de requete que plus haut pour les message on affiche , pourquoi cela ne peut pas fonctionner ?

j'ai jamais dis que ta methode etait plus lente, je croyais juste que tu n'avais pas compris ce que je voulais dire.
 
 

oué, en fait c'est ma methode, c'est juste que tu as enlevé l'id_reponse et tu l'as remplacé par ce que j'avais appelé "num_message"

Je ne sais pas ce que que j'ai enlever mais c'est toi qui plus haut a citer mon post en rajoutant un champ a mon MCD ...
 
Enfin bref désolé d'avoir plagié ton idée  
 
Bonne soirée ...

c pas mon idée

ta requête sera lente en ce sens que tu filtres sur 2 champs, dont l'id du topic, ce qui est mauvais car MySQL va du coup passer en revue tous les rows liés à ce topic. J'en fais l'expérience depuis hier et je n'ai pas encore la bonne solution, je continue à creuser (bientôt en Nouvelle-Zélande )

Si tu poses un index sur ces deux champs, ca devrait aller non ?

non, MySQL a l'air de ne jouer qu'avec un seul index à tous les coups, et ça m'ennuie beaucoup  (rien que pour avoir l'usage de l'index pour le tri est une prise de tête)

Au risque de repeter, id_sujet et id_message est un clé primaire composé ...  
j'ignore si ça genere réélement 1 seul index ou deux distinct mais d'un point de vue d'une analyse Merisienne c'est tout à fait viable...

Tu fais UN index sur les deux champs

j'y ai bien pensé mais ça m'a donné le même résultat au niveau perfs, et je ne pige pas bien pourquoi. Faudra que je réessaie

et si tu fais :
 
SELECT post FROM `table_post`  
WHERE id_sujet = ".$sujet_en_cours."
AND id_message >= ".($page_en_cours*$nb_post_par_page)."
LIMIT 25
 
 

ca sous entend qu'il n'y a aucun trous dans tes id_message.

ça sous-entend de faire une recherche sur 2 éléments, et sur une première page, MySQL va scanner toutes les premières pages de tous les topics
 
donc l'arme ultime consiste à avoir un identifiant de page unique pour chaque page de messages dans la table des messages (je sais pas si jme suis bien fait comprendre ) et faire une recherche sur ce seul index. Au pire tu ramènes plus d'une page dans le cas où l'utilisateur veut afficher un nombre différent de messages par page, mais ça restera largement inférieur au nombre de messages qu'il aurait scanné en faisant un select sur base de l'id des topics et l'id des messages.
 
Bon, je me prends tellement la tête là-dessus que je crois que je vais mettre ça de côté pour finir la 0.1 et j'intégrerai cette fonction dans la 0.2

Juste pour info, la V5 de Skylight utilise la fonction LIMIT et pourtant les temps sont plus que corrects (j'ai regardé hier soir).

 
ça c'est la condition requise à tous les précedent post depuis l'archive 161

 
phpBB utilise LIMIT et pourtant ils ont du se creuser la tête aussi je me demande pkoi ils n'ont pas fait la technique dites plus haut ...  

pour info, la gueule de ma DB de tests:
 

 
Le but était d'avoir quelques gros topics sans générer une DB énorme. Les temps sont relativement acceptables, mais la DB n'est pas trop réaliste: sur une DB de la taille d'HFR, ce serait catastrophique (car je MySQL scannerait beaucoup plus d'enregistrements).

Les perfs n'ont jamais intéressé le phpBB Team, sinon il serait pas ce qu'il est aujourd'hui C'est un peu plus surprennant pour un soft comme IVB, dont les perfs en v1.3 sont catastrophiques. Faudrait voir si le MCD a été revu sur leur v2.

la révision du MCD, c'est un point qui me fait peur. Vous aurez remarqué ici que suite à la suppression des splits, les topics splittés qui étaient autrefois liés entre eux ne le sont plus du tout, et n'ont pas été fusionnés non plus. Donc, pas de compatibilité ascendante. C'est un point auquel je tiens plus que tout, donc je VEUX trouver la solution idéale avant de répandre mon forum sur le ternet mondial

 
Alors ça marche la technique ?

pas encore, mais ça viendra

Pour IPB, il devient de plus en plus lourd à chaque version (j'ai voulu tester la V 2.0 et ... Sans commentaires pour ne pas être grossier.

J'utilise une clé a 3 champs, ce qui restreint beaucoup les lignes que MySQL doit parcourir
:
 
WHERE A.id_forum     = ".$infos_sujet["id_forum"]."
            AND A.id_categorie = ".$infos_sujet["id_categorie"]."
            AND A.id_sujet     = $s

M'enfin personnellement, mon intérêt était plutot (concernant ma v5), l'amélioration des performances (dans mes limites), une interface simple,légère et standard (xhtml 1.1 + css2) (les gens non initiés à internet doivent pouvoir comprendre vite comment ca marche) et l'accessibilité (feuille de style alternative pour déficients visuels, testez donc )

Je trouve que ca reste un excellent produit. Il est relativement rapide, et en terme de fonctionnalité c'est ce qui se fait de mieux aujourd'hui en logiciel de forum, l'interface d'administration est très complète, sans que l'ergonomie n'en souffre. Dommage qu'il soit totalement inadapté à de grosses bases.

 
Avec ton exemple mySQL doit parcourir 3 index non ?

Beh à priori, les 3 champs sont regroupés en un seul et même index, donc ca zieute juste sur un index

J'ai dit que j'utilisais une clé à 3 champs
ca limite les mêmes occurences, dont je pense que c'est assez rapide à parcourir ...