Reprise du message précédent :
Les splits d'antant étaient quand même éditables par les modos

harkoBot >>

Malheureusement non, il est au contraire particulièrement lent Même sur un champ indexé :
 

 
Ma table message contient 6 778 639 posts dont 1 372 315 sur le forum 1, et le champ forum est évidement indexé. Les COUNT sont vraiment très gourmands.

en fait le select count est optimisé seulement sans clause "where", c'est a dire select count(*) from table

Fabien & Core 666 > Ha effectivement, au temps pour moi alors

Oui tout à fait. Là c'est une donnée qui est stockée en dur dans le fichier index d'ailleurs, il n'y a rien à parcourir

 
à mon avis vaut mieux pousser cette idée à l'extrème à ce moment comme je l'avais suggéré plus haut je crois : tu numérotes carrément tous les messages un par un. Comme ça au moins au niveau de la lecture tu n'auras aucun problème de gestion tout en laissant la possibilité à l'utilisateur de régler le nombre de message par page.
t'as le même inconvénient par contre : pas de suppression possible pour les anciens messages (ça serait beaucoup trop lent si y'a des milliers de messages).
pour ton histoire de lock y'a pas besoin a priori : tu faits ton insert, ensuite tu fait un select pour voir le lock id qu'il fallait mettre et tu fais un update pour le mettre

certes, mais les splits impliquaient un nouveau topic après chaque split, donc pas d'effet de bord à craindre.

oui, comme quoi, faut creuser encore un peu, mais je pense que je ne suis pas loin d'une solution tout à fait viable (en fait, il me semble que j'y avais pensé un moment mais j'ai dû oublier  Au pire, si on efface, on met à jour la numérotation avec un petit update

Donc en fait tu veux stocker le numéro de la page a laquelle appartient chaques messages dans la table message. Le LIMIT est donc si gourmand que ça ?
Car pour enlever la personnalisation du nombre de post par page, il faut vraiment que le gain soit visible

le LIMIT est bourrin: il lira autant de rows que nécessaire jusqu'à rencontrer la condition. Dans le cas de lecture de dernières pages (ou en plein milieu), il lira la moitié ou toutes les rows liées au topic (ce qui peut faire des dizaines de milliers, entrainant une chute sévère de performances). Avec l'histoire des nombres de messages par page spécifié par l'utilisateur, je peux me permettre de filtrer sur 2 numéros de pages contre une seule, sans pour autant surcharger le serveur.
 
Maintenant j'avais vu un autre problème avec le WHERE: je filtrais donc sur l'id du topic et l'id de page, mais dans l'EXPLAIN, MySQL lit toutes les rows qui répondent à l'une ou l'autre condition (alors que les deux champs sont indexés)  Ca me ramène dans les 1018 rows pour mon test, alors que j'aurais espéré 25 avec ces 2 conditions

 
Hum, interessant ça comme idée

Et si on efface :s

Pas tant que ça car tu ne peut plus gérer toi même le nombre de post par page, sauf en recalculant la page de chaque post ...
 
De plus la suppression d'un post entrainerais des calcul important pour la gestion des pages ...

le mieux est de stocker le numéro du message dans le topic, c'est maintenable facilement avec un update en cas d'effacement (et tu peux même afficher en triant là-dessus plutôt que sur la date, index plus petit), et avec un petit calcul, tu peux mettre une condition WHERE qui limitera fort bien le nombre de records retournés, et par là donc, ne pas charger le serveur inutilement (à part cette sombre histoire de WHERE dont je parlais plus haut)
 
edit: le seul truc qui m'ennuie, ce sont les boulets qui effacent leurs vieux messages (cfr blabla@prog), donc j'ai quand même envie de garder l'option de verrouiller les "vieux" messages.

Et pouquoi pas des splits invisibles?
 
Tu splittes et après  tu merges les topics à l'affichage. Pour savoir lesquels tu dois prendre tu fais une table en plus avec: IDTOPIC-IDSPLIT-NOMBREMESSAGES
 
C'est peut être lourd à gérer aussi

Et si on gérait un compteur i dans la table message qui serait son numéro. Si on accede à la page 5 et qu'il y a 25 post par page on selectionne le post where id_post > 25*5 and id_post < (25*5)+25 et c'est bon .
 
Si il y a suppression du post id_post = x alors on as selon les cas :
UPDATE post SET i = i-1 WHERE id_post > x
UPDATE post SET i = i+1 WHERE id_post < x
 
Qu'en pensez vous ? serait ce plus rapide qu'un limit ?
 
Autre question : si un count(*) sans clause where accede au compteur par une variable stocké en dur dans la table et non par un réel comptage, pourquoi ne pas utilisé des count(*) pour le nombre total de sujet,message et user affiché en bas de nos pages d'index ?

 
c'est ce que je fais  

+1 pour le nombre d'utilisateurs, mais je fais un sum sur un champ analogue dans la table des cats vu que les cats sont splitées en plusieurs tables chez moi.

et pkoi splitter ?, joce a réussier à faire fonctionner avec une grosse charge sans les splits.
 
D'ailleus pkoi il les avait mis en place à une époque ?

Le split était la seule méthode qu'il avait trouvé à l'époque. Maintenant il a trouvé mieux

Je vois que le titre reflète toujours bien l'actualité du topic
 
j'espère avoir trouvé mieux aussi

Moué mais ce n'est pas très très au point non plus, un topic de 1000 pages, va à la page 500, les temps de générations explosent

 
Heu, j'espère que ton forum ne compte qu'un seul et unique topic alors
 
Parce que les ID_POST ne se suivent pas nécessairement dans le même topic
 
Par exemple :
where id_post > 25*5 and id_post < (25*5)+25
 
Ca donnerait :
where id_post > 125 and id_post < 150
 
Pourquoi les ID_POST de CE topic à la page 5 seraient nécessairement entre 125 et 150
 
Par exemple :
Topic > On a les posts avec ID_POST = 1,3,85,129,222.
 
Ta requête voudra afficher :
where id_post > 25*1 and id_post < (25*1)+25
 
Donc, entre 25 et 50, ca tombe à l'eau
 
 
J'espère avoir été clair Ou alors j'ai rien compris

Rha chier, j'crois que j'ai tout faut
Tu parlais pas de l'ID_POST en auto-increment, l'ID du post quoi ?
 
Mais plutôt d'un autre champ, qu'on renseignera pour chaque topic indépendament ?

J'ai mal écris mais c'est le i qui doit être prisen référence pas le id_post c'est justement l'intéret du i de replacer le post_id vu que celui ci n'est pas fiable en terme de suivi.
 
Deplus il va de soit que je ne spécifiait pas l'id_topic dans mon exemple ... mais si tu veux tu peut rajouter AND topic_id = \"".$topic_en_cours."\" comme ça tu epargne les post des topic non concerné ...

 
oui excuse moi
 
en fait quand j'ai ecris :  
_______________________________________
Par exemple :  
where id_post > 25*5 and id_post < (25*5)+25  
 
Ca donnerait :  
where id_post > 125 and id_post < 150  
__________________________________________
 
 
J'aurais du ecrire
 
Par exemple :  
where i > 25*5 and i < (25*5)+25  
 
Ca donnerait :  
where i > 125 and i < 150  
 
désolé

 
Le problème que je rencontre actuellement (merci access   ), c'est qu'il n'existe aucune alternative au limit. La seule possibilité est un select top from select top from, mais les temps de traitements augmentent avec le nombre de messages , et 2 secondes pour une requête et 120 000 messages, c'est trop, beaucoup trop, voir même anormal   .

 
Dans ton cas "celui ou on utilise un SGBD ne connaissant pas LIMIT" je recommande de numéroter toi meme chacuns des post selon le sujet et de renumeroté via des requete UPDATE en cas de suppression de post comme je l'ai indiqué plus haut comme ça tu pourra ne selectionner que les post necessaire a l'affiche de la page voulue et du nombre de post par page voulue .

Comment tu fais pour avoir la 100e page de réponses, dont l'auteur est karamilo (condition totalement bidon).
Tu pourrais avoir comme numerotation :
2,302,405,...
Ca revient au meme probleme qu'avec les ids. Donc la numerotation convient uniquement aux forums simples, si tu veux lister des trucs en fonction de certaines choses comme les flags, les auteurs, les ... Ca devient inefficace.

j'ai lu toute vos propositions, et je trouve que le mieux est d'interdire d'effacer les anciens messages, juste de pouvoir les editer, comme cela on peut mettre des index a chaque message qui pourrait servir de repere comme par exemple le numero de la page ou le numero du message (1er message, 2eme message, 100 eme message , ... )

 
Effectivement    
 
Mais on parle d'un affichage ordonnée par page d'un certain nombre de post c'est tout, ton exemple convient plus à l'affichage d'une page de resultat de recherche complexe "fonction rechercher".
 
La page d'affichage des messages peut se contenter de l'idée expliqué plus haut(a savoir la création d'un compteur dans la table message)

j'ai donc testé des requêtes sur une DB avec les messages avec  une numérotation liée au topic au lien de mon concept de "pages" mais au lieu d'avoir 10ms (avec les "pages" ), j'ai 100ms de temps d'exécution (cependant, la machine du second test est plus lente, je devrai attendre d'être rentré pour avoir un bench en rapport avec le premier).  
 
La raison est qu'il rapporte plus de rows (6018 au lieu de 1000 et des poussières). Et ceci parce que j'ai plus de chances de trouver des messages numérotés de 1 à 25 que de "pages" numérotées 1 (puisque ce bon dieu de MySQL semble vouloir faire un OR avant de faire le AND que je lui ai demandé dans ma clause WHERE ).

 
non car du id_message 1 au id_message 100 il a pu y avoir jusqu'a 100 topic different ...
Tu ne peut pas prendre les post en te basant sur l'index meme si aucune suppression n'es presente car l'ordre ne tiens pas compte des sujets ...
 
Il faut donc que l'identifiant du message soit un clef qui inclue l'identifiant du sujet
 
Pour ceux qui connaissent Merise, c'est un truc de ce genre :
__________                           ____________
|Sujet   |1,n                   (1,1)|Message   |
|id_sujet|----------(Appartenir)-----|id_message|
|________|                           |__________|
 

bon, j'ai rien dit, j'ai testé les 2 cas sur la même DB maintenant et ça me met dedans dans les 2 cas (et ça serait pire sur un forum comme HFR), donc c'est pas encore ça  Mais ma remarque sur la gestion des AND dans les clauses WHERE reste valable

Rainbow_Efreet > oui, j'avais vaguement pensé à une table externe au début, j'avais laissé tombé rapidement pour d'obscures raisons dont je ne me rappelle plus, et en fait, c'est évident quand on voit comment les clauses WHERE sont gérées: il faut pouvoir n'utiliser qu'un seul champ pour retrouver le groupe de messages dont on a besoin. Donc, une clé qui soit unique au topic et au message (ou groupe de messages). Perso, je préférerais la notion de groupes de messages, moins d'ids différents à gérer

 
Je vais tester avec le numéro des pages et ta solution.
Je pense néanmoins qu'avec la gestion des pages, on peut faire quelques choses d'intéressant et de rapide. A tester...

dans la table message tu rajoute un champ num_reponse, pour savoir quel est le numero de la reponse.
 

 
Ca marche    
 
Je suis passé de 42 secondes pour une requête non 'caché' (+ 112 000 sujets) à 0,04sec . Merveilleux...

Merci Fabien mais num message est inutile car etant donnée que j'ai mis des parenthese au cardinalité de message ça signifie que la clé primaire de sujet compose la clé primaire de message
 
PS : Dis tu m'apprendra a faire des beaux dessins comme ça

 
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.