Reprise du message précédent :

 
Il l'a modifié

Bah j'ai jamais pigé comment vous splittez de manière invisible ? C'est quoi qui change ? Comment tu sais quel split prendre pour faire l'affichage ?

Si le numéro de message > X, alors topic id = yyy
 
Nah ??

C'est crade...

C'est clair perso je trouve ça crade :-(

Hum, ça ne me plait pas trop non plus cette technique

C'est grosso modo sur le principe de split nah ?

bah perso c'est ce principe qui me plait pas ouais

Rigolo de faire mumuse avec le trash_post=1 dans l'url sur MD , on retrouve tous les posts effacés dans tous les topics (simplement cachés en fait => rapport avec la méthode de listing de Joce : y doit p/e pas avoir d'ID intra-topic car les posts non visibles auraient aussi un ID intra-topic et y faudrait en tenir compte, ça deviendrait le bordel. Ou alors peut être pour éviter les trous dans une suite d'ID, mais je vois pas trop comment s'en sortir quand même après). On retrouve même des bout de code de MD indélicatement recopiés lors des crashs/tests par certains en cherchant bien . function md_get_pseudo_cookie ou md_slave_wait_master ça te parle Joce ? c'est peut être modifié depuis d'ailleurs

 
Y'a aussi le trash=1 mais je sais pas ce qu'il fait celui-là ^^  

 
Ouaip... Je veux bien dénormaliser un peu sur certains trucs, mais là c'est vraiment dégueu!

nan, pas moi!

 
Il me semble que les posts supprimés restaurés viennent se placer à la fin du topic... ce qui collerait au système des ID, mais ça n'explique pas pourquoi ils apparaissent au bon endroit du topic quand on l'affiche (la découpe en pages ignore bien les messages supprimés, même quand ils sont affichés pour les modos).

le système de joce suppose qu'un message peut disparaître, mais ne peut apparaître qu'en dernière position ...

On en est toujours à parler de la façon de découper les pages de topics ? J'abandonne le topic pendant des semaines et quand je reviens le sujet a pas changé
Comme chez OHV j'ai pas droit aux tables temporaire j'ai dû faire sans : je fais un select des ID de messages avec un limit (rapide vu que les ID sont indexés et que je ne prends que ça), puis je prends le min et le max dans cette liste d'ID pour faire un select avec between des messages + jointure sur autre table, sans limit cette fois-ci. Et pas besoin de gérer la suppression des ID, y a des trous et ça ne gêne pas.

 
Tiens donc! Mon système de restauration remet les posts supprimés à leur place...

+1

Ah intéressant   mais oui le gros problème c'est que le nombre de posts affichés est constant, même si sur cette page il y a des replys cachés à la bonne place, il faudrait qu'il vérifie s'il y a des trucs cachés à chaque fois et en tenir compte pour aller chercher N+X id avec X=nombre de replys cachés, puis enlever les invisibles, c'est pour ça que je trouve ça bordélique, pas applicable et c'est probablement pas ça...
 

Y a pas de LIMIT dans la 2ème requête normalement, on balance juste les ID trouvés dans un IN() pour aller chercher les data correspondantes et y a même pas besoin de les trier, c'est déjà fait à la 1ère. A quoi sert le BETWEEN alors que t'obtiens une liste d'ID et non pas 2 bornes inf et sup directement ? Tu calcules a posteriori un min et un max "pour rien" disons, le IN étant probablement aussi rapide que le BETWEEN. T'as comparé ?

Donc y'a un LIMIT dans une des requêtes de Joce alors, seulement comment peut-il se targuer d'offrir des performances qui surclassent toutes les solutions concurrentes ? je pense qu'il faudrait qu'on se monte un forum commercial en concurrence

je doute très fort qu'il y'ait un LIMIT quelque part dans la solution de Joce...

Oui pareil, car à force le LIMIT devient vite lourd quand même, même en ne travaillant que sur des ID indexés à trier... Le fait de scinder la requête à la con limite bien la casse mais ce n'est qu'un palliatif en attendant mieux.

En effet, comme je le disais "sans limit cette fois-ci".
Je calcule pas vraiment pour rien, je prends juste le 1er et le dernier de ce qu'il me renvoie.
J'ai pas fait des tests comparatifs, vu que je vois pas trop l'intérêt du IN : dans les deux cas on doit lire la liste des id retournés, et je doute qu'un IN sur une liste puisse être mieux qu'un BETWEEN sur deux valeurs...

en attendant ça a résolu mon problème de performances sur imcdb, où il y a environ 100 000 commentaires affichés en un seul "topic" dans une des vues (celle qui affiche les derniers commentaires postés, mais avec une découpe de pages de l'ensemble des commentaires)

C'est justement le truc que je te demandais si t'avais comparé . Mettre 20-30 id dans une chaine pour balancer dans le IN c'est pas pénalisant. En +, toi tu dois faire un 2ème ORDER dans la 2ème requête car le BETWEEN perd cette information avec la borne sup et inf. T'as déjà du faire un ORDER sur la 1ère requête pour choisir la bonne tranche d'ID.
 
EDIT : C'est où ton topic imcdb?

Depuis quand il te renvoie les valeurs dans l'odre du contenu du IN ? (ou alors c'est une spécifité de MySQL ? Ou j'ai raté un truc dans mes cours de SQL )

mon topic? non, un site  
www.imcdb.org
et la page qui affiche les 100 000 commentaires splittés en une page :  
http://www.imcdb.org/yourcomments. [...] nts&page=1
Parfois ça rame, faut pas oublier que c'est du mutualisé chez OVH, qu'y a du monde, et que les regexp pour l'affichage des messages ne sont pas spécialement optimisées - je pense que c'est clairement les regexp que je devrais améliorer, vu que le contenu des messages et ce que j'active/désactive comme regexp joue beaucoup ; les requêtes sont rapides maintenant.

J'ai un ORDER dans la 1ère requête avec le LIMIT et la chaine balancée dans le IN de la 2ème requête garde l'ordre, les résultats qui sortent de la 2ème requête restent classés à la fin (1er id de IN donne 1er résultat, 2ème donne 2ème, etc.).

Donc tu me dis que un SELECT * FROM ... WHERE ID IN (1,3,5,7,9,2,4,6,8,10) va donner des résultats dans l'ordre de ces ID ?
Qu'il soient triés sur la clé ça me semble logique, mais triés sur le contenu du IN j'ai jamais entendu parler de ça ?

Antp > Je pense que j'ai pigé ce que tu disais et je complète .
 
Je dois préciser qu'il y a effectivement une petite part d'ombre car j'ai fait la même chose pour lister les sujets et là je suis obligé de mettre un ORDER dans la 2ème requête pour reclasser car le IN() ne tient pas compte de l'ordre de la liste ! Et pourtant ce sont strictement les mêmes méthodes et je n'ai toujorus pas compris pourquoi il ne veut pas, la liste injectée dans le IN est dans le bon ordre d'affichage (c'est modulable) et pourtant en sortie bah il change cet ordre. Par contre pour lister les replys, il n'y a aucun ORDER et ça passe sans problème, c'est toujours l'ordre de la liste d'ID qui est respectée. Faudra que je revois ça quand j'aurais un peu de temps car la résultat n'est pas logique.

Dans certains cas les résultats sont triés sur la clé primaire je suppose...  
Teste en inversant l'ordre de ce que tu passes dans le IN pour voir si ça inverse les replys

C'est ce que je me suis dis en allant pisser , je viens d'avoir la même flash, c'est un problème de clé, dans un cas j'ai une primaire et dans l'autre c'est un index simple... Sur la primaire, l'ordre est gardé.
Enfin ça m'évite un ORDER c'est pas plus mal, même si order sur 20-30 lignes c'est pas méchant.

en MP ca aurait ete un peu plus elegant

Au fait, il y a un bug dans la recherche rapide. Quand on click sur la deuxième page de résultat de recherche, on se retrouve dans la deuxième page de la catégorie (on perd la recherche).

ouaip ca je sais, c'est deja corrige en local (et c'est pas uniquement pour la recherche rapide en fait)

 
C'est ce que je viens de voir aussi. En plus je suis pas dans le bon topic et c'était déjà signalé dans le topic bug du forum. Tout faux   .

Troll

Je pense que le fait de regarder les temps de génération de certaines pages dans un gros topic peu nous en dire plus sur la technique qu'utilise joce. De mémoire les pages 'au centre du topic' sont les plus longues

hihihi, toujours les vendeurs qui sont contre le full disclosure ...

La culture du secret caylemal , faut faire profiter et ça permet de discuter sur les méthodes employées même si on fait du sur-place un peu quand même
M'enfin la "faille" est comblée maintenant.

Non c'est pareil. Je viens de regarder sur le topic de 16000 pages ds Blabla, entre ~0.150 et 0.170 s pour la 1ère, le milieu ou la fin du topic. Sa méthode est "optimale" selon Joce et la position intra-topic n'a aucune influence sur le résultat

ha? t'as fait une etude de marché ?
 
 

Bah nan c'est la technique qu'il a adoptée le adsense dessus