Reprise du message précédent :

L'impact n'est pas lié au limit mais à l'offset élevé

 
Parce qu'un "LIMIT 0, 50" traite et récupère 50 résultats tandis qu'un "LIMIT 500000, 50" traite 500000 résultat pour en retourner 50
 

 
Je sais bien oui, mais on me fait comprendre qu'une table de navigation n'est pas une bonne idée à cause des ressources utilisées pour la suppression d'un post (et qu'en cas de mass delete ça va foutre le serveur sur les rotules), tandis qu'un limit bouffe beaucoup de ressource lorsqu'on atteint un offset élevé.
 
J'essaye donc de trouver un compromis entre les deux.

La méthode du between fonctionne dans tous les cas ! Non ?
Si oui, pourquoi vouloir ne la réserver que dans certains cas, et utiliser une autre méthode dans d'autres cas ?

La mise en cache

Parce qu'une table de navigation pour un topic de 1.000.000 de post par exemple va contenir l'ID de tous les posts, ainsi que leur "position" :

Il se passe quoi quand tu supprimes le post 32 ? => il faut recalculer le champ "POS" des 999997 posts qui le suivent avec du "POS - 1", ce qui est "très très très long".

Donc si en plus tu massdelete un gugus et qu'il a par exemple 60 posts vers le debut du topic, ben tu fais 60 fois "très très très long"

Oué mais je doute que le cache de la page 1732 sur 4871 du topic 3218 sera réutilisé souvent vois tu

J'ai lancé un massdelete de 13000 posts ... je vous dirais quand ça sera fini

Edit : pour info j'en suis à ~16 minutes

Bah non, tu le fais qu'une fois sur chaque topic, ça

C'est trop. Marque les pour effacement puis efface-les pendant une phase de maintenance. Un update te coûtera moins cher qu'un delete.

FOR EACH ROW BEGIN
    DELETE FROM nav WHERE post_id = OLD.id;
    UPDATE nav SET pos = pos - 1 WHERE post_id > OLD.id;
END//

 
T'es bien obligé de tout recalculer à chaque suppression de ligne ...

Dans ce cas il peut plus utiliser between, qui est justement ce qu'il veut faire

FOR EACH ROW BEGIN
    DELETE FROM nav WHERE post_id = OLD.id;
    UPDATE nav SET pos = pos - 1 WHERE post_id > OLD.id;
END//

Ben non, tu mets tout dans une transaction, tu commences par supprimer tous les posts puis tu recalcules tous les ids positionels, et tu commit.

FOR EACH ROW BEGIN
    DELETE FROM nav WHERE post_id = OLD.id;
    UPDATE nav SET pos = pos - 1 WHERE post_id > OLD.id;
END//

C'est pas de l'algo optimisé ça

FOR EACH ROW BEGIN
    DELETE FROM nav WHERE post_id = OLD.id;
END//
 
ID = 0;
FOR EACH ROW ORDER BY POST_ID BEGIN
    UPDATE nav SET pos = ID++;
END//

 
Je sais, mais même de cette manière ça sera trop long quand même... On peu tpas fermer un forum pendant 3h même s'il est 2h du mat, juste pour supprimer des messages ...
 
Nan je pense que je vais foutre un flag "deleted" à 1, et laisse comme ça...
 
Et à l'affichage on aura :

 
Alors du coup je sais que si sur un page de 30 posts y'avait 25 posts d'un user massdeleté ça va foutre 25 fois "message supprimé" et il ne restera que 5 posts à lire mais :
 
1> Est-ce si courant de mass-delete un user ?
2> A-t-on vraiment souvent 25 posts d'un même user sur un page de 30 posts
3> Quand bien même le 2> arriverait de tps en tps, est-ce vraiment dramatique ?
4> Ne pas oublier qu'en cas de suppression "normal" d'un post par un modo/user, le message sera bien supprimé ... et interdiction de supprimer les messages de plus de X jours.
 
Je pense qu'en prenant tout ça en compte, ça devrait rouler.

Merci pour votre aide, je vais regarder ça de plus près

 
 
Avis perso, mais au niveau de l'interface utilisateur finale, je trouve ça à gerber.
les gens s'en foutent de voir des trucs "supprimés"
c'est comme sur clubic, donc ça fait moche
 

 
Oui et non, normalement, tout utilisateur doit pouvoir supprimer ses messages quand il veut, où il veut... loi de 1978

 
L'exemple n'est pas terrible, ça serait plutôt :
 

 
La loi dit qu'il a un droit de modification et de suppression des infos personnelles ... pas qu'il doit pouvoir le faire lui même

Wi, mais ça revient au même
 
Moi-même, je préfère voir une interface claire, épurée, sans informations inutiles... et pour la plupart des gens ça sera pareil !

Flag => caca, si ça affiche des pages qui au final n'ont pas le même nombre de posts

 
Je n'arrive pas comprendre ton code :
 

DELETE FROM nav WHERE post_id IN ids_to_delete;
ID=0;
FOR EACH ROW ORDER BY POST_ID BEGIN
    UPDATE nav SET post = ID++;
END//

 
C'est quoi, un trigger ? Le ids_to_delete il sort d'où ?

DELETE FROM nav WHERE post_id IN ids_to_delete;
ID=0;
FOR EACH ROW ORDER BY POST_ID BEGIN
    UPDATE nav SET post = ID++;
END//

Bah c'est la liste des posts à deleter.
mais masklinn a oublié qu'il fallait une requete pour récupérer les id des posts a deleter

Sans blague ?

Mais pour moi un FOR EACH ROW BEGIN ça veut dire "pour chaque ligne supprimée, fait ..."

Ce qui au final voudrait dire :

Pour chaque post supprimé fait "UPDATE nav SET post = ID++" ... ce qui n'a pas bcp de sens pour moi

Edit : À moins que le FOR EACH ROW est utilisable en dehors des trigger ... mais dans ce cas je ne vois aucune référence quant à la table à utiliser ...

DELETE FROM nav WHERE post_id IN ids_to_delete;
ID=0;
FOR EACH ROW ORDER BY POST_ID BEGIN
    UPDATE nav SET post = ID++;
END//

C'est pas du vrai SQL, c'est du pseudocode
 
Logiquement, si tu massdelete quelqu'un tu fais un delete sur tous les posts avec son userid dans la base/le topic, pas besoin d'itérer sur les posts.
 
Et si tu delete qu'un seul post, pas besoin d'itérer pour faire la suppression, puisqu'il n'y a qu'un post à supprimer

Ah, mais j'ai repris tes lignes de codes sans savoir que c'était des triggers. Moi je te parlais d'algo.
 
Grosso-modo : tu fais une boucle pour avoir les id des posts à supprimer.
Tu en fais un tableau.
(ou comme le dis masklinn, tu vires tous les posts selon l'id_user)
Tu fais une requête pour supprimer ces posts

 
Ensuite, vu que tu as plein de trous dans ta table, tu reparcours toute ta table (avec un WHERE sur le topic_id, et un ORDER BY post_id ASC), et tu renumérotes tous tes posts en une seule itération, pas la peine de réitérer à chaque suppression. (edit)
Chaque post a un identifiant unique, créé lors de la création du post, ils sont forcément croissants.

vala, pareil

1> ça dépend plus des utilisateurs, modérateurs, administrateurs.
2> idem
3> non
4> chez moi, peu importe qui procède à l'effacement, je mets l'id du mec qui a effacé dans un champ (nullable) prévu pour, dans la table des messages. Si le champ contient une valeur, le message est effacé, et je peux en prime savoir qui a effacé le message.

DJ, je veux aller à la page 48 du topic a flood, je fais comment ?

Je vais passer pour un gros con ... mais je vois toujours pas comment faire
 
Comment on fait une boucle en MySQL ?
 
DELETE FROM nav WHERE post_id IN (post_ids) ... mais la boucle après, pour recalculer pour un topic donné ?

Tu patientes et tu attends que je foute le champ pour accès direct à une page

 
Je sais Je m'en susi rendu compte Mais je sais toujours pas comment changer ça

Une fois que tu as viré tous les posts d'untel

Tu reparcours ta table en fonction de l'ordre de tes posts

A l'arrache, mais c'est comme ça que ça fonctionne.

C'est pas spécialement évident

Je suis pas sûr de comprendre ce que t'as pas compris, mais ce que font Masklinn & co, c'est tout supprimer, et *ensuite* recalculer les positions des posts qui restent...

Là où toi tu supprimais 1 par 1, et à chaque fois recalcule toute la table...

edit : en plus d'etre inutile, je suis grillé.

skylight> Ah oué mais là ça repasse par Php ... et ça fait X requêtes dans la BDD ... d'autant que pendant ce temps le topic reste en rade ... je trouve pas ça top du tout

theredled> Oui mais justement, je ne vois pas comment recalculer les positions, dans le même lock... Si quelqu'un tombe sur un topic pendant la suppression ça va être tout pété, moi je pensais qu'il existait un moyen de faire une boucle directement dans MySQL en fait, dans une procédure stockée...

D'ailleurs skylight, je comprends toujours pas ton code :
 

SELECT post_order FROM ta_table WHERE topic_id = xxx ORDER BY post_id ASC

 
Il sort d'où ce topic_id ? C'est pas un topic qu'on supprime ... c'est un user avec ses posts ...

Oui, mais quand tu va réarranger les compteurs de tes posts, va bien falloir que tu le fasses PAR topic.
 

 
Ah mais je sais bien, c'est bien pour ca que je te demande d'où tu sors ton topic_id là