Reprise du message précédent :
 
Ah wé mais là y a rien de dur, quel tricheur  

Justement, comment ?

Bof, comment se compliquer la vie pour pas grand chose je trouve. Tu peux te dire que les DELETE n'arriveront à 99.99% qu'en fin de topic (t'es du genre à faire des MASS DELETE?) donc que l'UPDATE ne tiendra que sur quelques ID seulement, donc extrêmement rapide. Je pense que le risque vaut la peine d'être couru et si un connard vient deleter en début d'énormes topics bah t'auras un UPDATE un peu plus lent c'est tout, ça ralentira qques secondes. Une limite dans le temps pour deleter les topics est aussi envisageable, ça évitera ce genre de choses

 
Y doit y'avoir un truc qui cloche, là... Un update sur 15000 lignes ne doit pas prendre plus de 1 à 2 secondes maxi sur un serveur préhistorique!

C'est ce que je me disais  
Au pire afficher un message genre "Le topic doit être resynchronisé..." pendant le big update; et split auto. tous les 15 000 pages

Je te trouve pas très cohérent (ou j'ai pas tout compris )
En fait tu viens de dire que décrémenter 50 000 posts ne post pas de problèmes ?
 
C'est donc faisable (d'autant plus que, comme le dit rosco, les cas de del. sur les premières pages d'un gros topic sont relativement rares)

Je pense que je vais pas tarder à remodifier mon truc aussi car rien que d'en parler ça me titille   et en mettant une limite de DELETE dans le temps (3 mois c'est bien, même 2..), ça interdira les gros UPDATE inutiles...

ça peut être une solution aussi...
 
Je vais tester ça et faire quelques "benchs" pour voir; sur 44 000 pages bien sûr

Pc_expert : tu sais que ta phrase sous ton pseudo n'est pas très tolérée sur ce forum ?

ah oui c'est vrai bah elle est très vieille donc bon j'y faisais même plus attention
 
Je vais la changer (merci à toi si ça peut m'éviter quelques pbs; on sait jamais ^^ )

 
Pourquoi pas cohérent? Les SGBD sont censés être à même de gérer ce genre de choses facilement. Je dis pas que ce sera fait en 0,0009 secondes, mais c'est pas la mort d'avoir un update de plusieurs dizaines de milliers de lignes de temps à autres, quitte à ce que ça prenne 2 secondes au lieu de quelques millisecondes pour la majeure partie des updates. Le but est quand même d'obtenir des perfs maximales à l'affichage, ce qui représente 90% des requêtes en rapport avec les topics...

Tout à fait d'accord
Faut bien voir où sont les priorités, et si tu dois sacrifier 2 secondes 1 fois tous les 2 mois, alors qu'à côté t'as des temps de parcours de topics instantanés, bah je fonce moi

mmmm ok en fait j'avais mal compris ça:

 
mea culpa
 
Mais si c'est si simple alors pourquoi on a parlé de topics marqueurs ou je ne sais quelles solutions compliquées avant ?

Parce que l'optimisation ultime est encore mieux

Sûrement mais apparemment personne ne veut la donner/l'a trouvée (Joce )

La solution BETWEEN + champ de position est une solution, pas LA solution. Il existe probablement ( ) des méthodes meilleures ou des optimisations qui permettent de faire mieux! Pis c'est assez lourd à gérer quand même, faut vraiment bien ficeler son truc si on veut pas de merde entre :
 
- les remontages de topics
- les delete de posts
- les topics "sticky"
- les affichages avec filtre
- les sous-cat
et j'en passe...

J'ai essayé de parcourir les forums officiels de MySQL (un phorum; spa optimisé tout ça il me semble ) et j'ai rien trouvé

Soul > Vas-y accouche

Il y a la double requette avec une table temporaire d'id, mais ça rallentit le systeme avec les topic ou il n'y a quasi pas de post...
 
sinon une table qui contient les troues dans les topics

Sans table temporaire c'est mieux  
EDIT : Pas de ralentissement pour les topics à 1 page moi, SQL ne prend que 0.01 sec sur un Cobalt moisi mutualisé.

Yep j'y ai pensé, mais j'ai pas réussi à le mettre en place
 
Trop difficile de gérer ça avec le BETWEEN

Tu arrives a passer en une seule requette sur mysql 4.0 ? (faudra que je mette a jour ma poubelle un de ces quattre )

   
Si ça s'adresse à moi, c'est le temps total SQL pour afficher le topic avec toutes les requêtes associées.

je disais sans passer par la table temporaire je sais bien que c'est le temps pour toutes les requettes

Inutile. Si quelqu'un vient poster entre des delete ca va foutre le boxon.
Je suis d'accord avec rosco. Tu dois avoir 99% de suppresion en fin de topic, et 0.1% de suppresion pour chaque topic créé ou lu. Et puis au pire, si quelqu'un supprime en début de topic je vois pas quel est le problème pour un sgbd d'updater des milliers de lignes.
Vaut mieux priviligier la lecture plutot que l'ecriture ou la suppression de post
 
Eit: Jsuis aussi d'accord avec soulmanto
 

Chaced > Bah j'ai scindé les requêtes en 2 comme j'avais présenté + haut, je comprends pas trop ce que tu veux dire en fait ou alors t'avais pas vu le post en question

 
Je crois pourtant que c'est ce que fait Joce.

C'est l'idée qu'il a donné, mais pas celle qu'il utilise il me semble bien.

M'étonnerait fort, c'est un peu pénalisant les temporary et y MySQL devrait en gérer un sacré nombre (limite?). Il a juste évoqué une requête une fois.

ça fonctionne comment une temporaire ? elle est détruite au mysql_close ?

Oui ca se détruit quand la connection à la BDD s'arrête. Heureusement sinon la place que ça prendrait

On ne sait jamais, avec les liens persistant et compagnie
 
Mais bon c'est vrai que mon serveur a un uptime de 96jour et la mémoire n'a pas encore explosé

sur mon forum c'est accepté
 

mais je crois que j'ai la solution, mais pour l'instant c'est de la theorie, je l'ai pas encore testé. Mais ce devrait marcher. je la donne pas encore, car j'ai pas envie que vous m'enbrouillez
Mais je l'ai dis, c'est presque le principe d'un split "invisible", on coupe les gros topic en petite partie pour faire un order by sur peu de ligne.
ya meme pas de between dans ma solution
 

Joce c'est un IN() presque à coup sûr je pense

Joce c'est un IN() sur la page de listing des topics il me semble ouais

Oui alors pkoi pas ds les topics aussi
Le truc inconnu c'est sur quels critères aller chercher les ID, un truc doit nous échapper, ça doit être évident vu que c'est qu'un Joce quoi  

On peut appliquer le même dawa que tout à l'heure
 
where pid IN(0,1... 39)
en ce basant sur les IDs intra-topic
 
Mais même problème pour la suppression
 
Il doit y avoir un autre moyen

Bah c'est pas le IN() le problème, j'utilise ça pour le listing des topics et des posts moi. C'est ce qu'il faut lui donner à manger à ce IN() qui pose problème

Héhé on parle de mes topics marqueurs
 
Le splitagge je trouve que c'est super simple comme technique. Par contre j'ai pas assez de gros topic pour que ce soit visible...

 
Il l'a modifié