Reprise du message précédent :
Rainbow_Ef reet > Tu l'insére en zéro et t'augmente tout le monde de 1. (bon, ok, c'est le point noir de la méthode)

oui il est même très noir

Et comment tu gères les topics "sticky" en insérant en 0?

Et si on prend le raisonement a l'envers.
 
On a un champ position, qui indique le position, mais le plus gros chiffre se trouve en premier dans le classement.
 
Donc a la mise a jour ou a un insert, il suffit de faire un position=max(position) + 1
 
Bon apres il reste toujours le probleme en cas de suppression d'un topic, on est obligé d'avoir une table qui indexe les topics supprimés

Tu as 5 topic,
les numéros de position sont 1, 2, 3, 4, 5
Le 4 a une nouvelle réponse il prend donc la position 6 (5 + 1).
les numéros de position sont 1, 2, 3, 5, 6
On a un trou (le 4eme) sans avoir eu de suppréssion

ok a revoir
 
ça serait tellement plus simple d'utiliser un limit

Il suffit d'utiliser limit mais pas sur n'importe quelle table  

 
Oui limit en reccuperant uniquement position, puis un petit left join avec les nombres réccupérés...

Pour moi si tu fais un limit c'est justement pour t'abstenir de champ position donc non c'est uniquement pour récupérer les ID.
Ensuite une autre requête ira chercher des topics avec la commande sql IN ().
 
Et ce sans left join  

 
Le left join c'est quand on a un mysql qui n'aime pas les requettes imbriquée

Non plus tu stock les ID's dans un tableau et tu fais :
 
IN('.implode(', ', $mesIDs).')
 
Ce qui fais deux requêtes sans left join.

EDIT: Nan jallais dire une connerie

Avec une requette imbriqué tu te passes de ton retour a php, mysql traite tout de lui meme en une seule passe

Certes mais quand mySQL ne gère pas les requêtes imbriqués, et qu'on ne veux pas utiliser LEFT JOIN et bien ce retour à PHP est donc bien pratique et je t'encourage à tester ses performances.

oui c'est sur, en fait faut faire les 2 cas, si mysql < 4.1 et >=

Je pense avoir trouvé une solution.
 
Si on fait un nouveau sujet dans une categorie comportant 100 pages on fait seulement 200 updates au lieux de 2000, et quand on ajoute une réponse dans la page 1 (donc dans la majorité des cas)ca fait rien du tout, quand on ajoute une réponse dans la page x, ca fait 2x update.
 
Je verifie une dernière fois

C'est le principe des pages marqueurs, une toutes les X topics, non? Je sais plus qui avait proposé ça plus haut...

Pas exactement. Tout topic a un numero de page, de sorte que j'update seulement 1 topic qui change de page.
Et après c'est nickel, parce-que ca fait SELECT * from sujet WHERE id-cat='' AND page='' ORDER BY reponse
 
Pas bien méchant comme requete ca

ca peut pas marcher là, tu n'auras pas des pages avec le meme nombre de topic.

Wé d'accord, mais quand un topic change de page à la création d'un nouveau, y a pas qu'un seul topic à changer mais autant de topics que de pages dans la cat (le dernier topic de chaque page en fait) vu qu'on décale de 1 partout. Et si qqu'un remonte plusieurs topics des pages antérieures, faut à chaque fois updater toutes les positions de tous les topics de fin de page des pages d'avant, ça devient lourdingue.

 
Le coup de l'update quand tu crées un topic ouais c'est le point noir, pour les sticky tu les fous en -1 et hop... t'es plus emmerdé (c'est ce que je fais)
 

 
Le problème de ça est qu'il faut stocker le nombre maxi de topics quelque part sinon t'as une requête en plus à faire, mais c'est pas une mauvaise idée car en cas de nouveau topic c'est instantané (max + 1) et en cas d'update, vu que t'as stocké le max quelque part, tu récupères l'id du topic en cours et tous les topics qui sont compris entre l'id du topic en cours et max ont leur marqueur de position diminué de 1, et le topic auquel tu réponds voit son id qui vaut l'id maxi.
 

 
Le problème est que tu peux plus dire à tes utilisateurs de choisir un nombre de topics par page, t'es bridé. Sinon ça serait pas con du tout de stocker des numéros de page, ça serait instantanné, mais en cas de suppression bonjour les emmerdes pour tout recalculer...

C'est exactement ce que j'ai dit.
Bah cest moins lourdingue qu'updater tous les sujets. SI j'ai 100 pages et que je crée un nouveau topic ca fait 200 update, c'est pas la mort

Donc faut mieux faire 200 update ou un limit qui trie seulement sur un index ?

LIMIT c'est + simple  

Mais largement plus lent

J'ai déjà fait le choix de mettre un nombre de tpoic fixe. Ca pose pleins d'emmerdes sinon et 90% des utilisateurs savent meme pas que ca existe    
 
La suppression c'est comme la reponse. Une suppression en page 20 engendre 2x20 update  

Bah un limit , actuellement ca me prend une dizaine de secondes sur 3 millions de topics.  
Un update ca m'en prends meme pas 0.001
 
Et y'a plus de lectures que de nouveau sujet.
De meme qu'il y a plus de reponses dans la première page que dans les autres. L'avantage de ma solution cest que repondre en page 1 ca fait rien du tout

Bof pas tant que ça, t'as pas 50000 topics par cat en général et le LIMIT reste à LIMIT 0, X avec X=nbre de topics/pages car la 1ère page est la + regardée de très loin.

 
c'esr sur si on fait un limit sur 3millions de post, meme en fesant le select que sur un champ de 8octet, ça fait tout desuite enorme

Euh attendez ce que je vous raconte ca veut dire que on update 300 000 messages pour une categorie de 3 millions de messages quand on fait un nouveau sujet.
C'est normal que chez moi ca prend 20 secondes pour updater 300 000 messages?

heu, ça fait beaucoup 20 secondes XD

C'est bien ce qui me semblait!
Qu'est-ce que j'ai fichu

Ca me donnait la même chose il me semble

Faut pas oublier que non seulement vous modifiez la table mais aussi les indexes
 
Perso je trouve pas ça viable (ce genre de discu a déjà eu lieu il y a 100 ou 200 pages). Vous faites comment en cas de mass-ban-delete du dernier boulet arrivé sur votre forum et qui n'aura pas manqué de créer des topics-à-la-con un peu partout?

EN mettant en place cette solution je me rends compte que meme s'il faut faire peu d'update, la solution est lourde.
 
Vous gardez le limit vous?

Pas de limit pour moi. Je vais vérifier les temps ce soir, mais sur ma base de test avec 1.500.000 messages, l'update résultant d'un nouveau topic est super rapide...

TU update 1.500.000 topic ou une aprtie des 1.500.000?

Juste une partie...

Bah moi pour l'instant je vais garder mes LIMIT façon optimisée car on vient de changer de serveur pour passer d'un vieux Cobalt je sais pas quoi (P3 1Ghz un truc du genre) à un BI-Xeon 2.8Ghz avec 2Go de ram et du raid, bah la différence est monstrueuse, ça bombarbe bien
Là où l'ancien mettait au mieux ~0.4-0.8 s pour traiter les requêtes SQL à aller en page 700 (on splittait), le nouveau met seulement ~0.007 sec à tout faire, presque 100x plus rapide
Y a même plus besoin d'optimiser tellement ça va vite , nan je blague on optimise quand même car c'est pas une raison et j'ai encore bien des choses à modder et ensuite passer au BETWEEN

Ah ok. PArce-que je testais a updater 3 millions de messages .
C'etait peut etre un peu trop
 
Joce, pourrais-tu nous dire combien de SUJETS il y a dans la plus grosse cat de hfr?