Reprise du message précédent :

seul problème. il faut enlever le is_last à l'ancien dernier.
 
à mon avec un index sur la date et rulez

moi je décrémente pas Nombre de messages postés, c'est pas pareil que nombre de messages actuel de cet utilisateur

 
Pas compris .. Qu'est-ce que ca veut dire?  

si tu mets un index logique sur la date c'est plus performant que ta bidouille à mon avis

Oui pour la date y a pas de probleme, mais pour l'auteur du message? Comment je fais pour le lier a la date en question sans retomber dans le probleme que j'ai énoncer avant?

Voilà, c'est exactement ça. Surtout que ca permet d'exploiter certaines choses intéressantes, notamment au niveau de la mise en cache. Mais le gain le plus important se situe au niveau de la gestion des verrous par MySQL, comme l'indique skylight.
 
J'avais de gros problèmes avec ca, ils sont réglés aujourd'hui. Et tout ca en conservant l'ensemble de mes tables en MyISAM. J'ai pas mal louché du côté des avantages de InnoDB, mais je tiens à la portabilité de mon code sur des hébergements mutualisés et il offre le même niveau de performance sous MySQL 4.x que sous MySQL 3.23, QUERY CACHE excepté (j'utilise aucune des spécificités de MySQL 4)

C'est ce que je fais Pourtant la requête est particulièrement simple. Je m'y suis repris à 3 fois pour créer ma page index, et j'ai finalement retenu une solution à une requête. Inconvénient : ca demande pas mal de post-traitement en PHP (au niveau de la gestion des sections privées notamment) mais c'est pas 100 if dans la page qui vont tuer le script.
 
On dispose de tellement de puissance CPU aujourd'hui que sur mes derniers développements j'essaye au maximum d'alléger MySQL, quitte à faire bosser un peu plus PHP. Et ca marche. Ceci dit j'ai quand même gardé une option dans mon panneau d'admin qui me permet en un clic de définir si je souhaite faire travailler davantage PHP ou MySQL

Tableau associatif dans lequel je stocke le nombre de message supprimés pour chaque user (avec valeur incrémentée à chaque passage de la boucle indiquant l'id du message à supprimer et l'id de l'auteur correspondant). Puis nouvelle boucle avec un update par auteur. Des requetes de ce type sont tellement rapides que tu peux en faire plus de 1000 par seconde sans que ca n'ait une indicence quelconque sur les perfs

Je vois que tu as la meme méthode que moi ... faire bosser plus php que mysql
 
c'est beau de faire des belles requetes, mais en créant des tableaux PHP, on se simplifie la vie (grace a des belles fonctions pour tableaux genre in_array() ..) et mysql bosse moins .. (on a du CPU, mais les disques , faut y penser aussi ! )
.

Et puis la RAM est tellement pus rapide que les HDDs ...

bon, j'ai un problème avec les drapeaux. Comme vous le savez sûrement, ici c'est simple, dès que vous cliquez sur un drapeau, il est mis à jour par rapport au dernier post du topic et basta. Mais quid si on a 10 pages de retard et qu'on a pas forcément envie de tout se taper directement? Genre je vais jusqu'à la page 2 et j'aimerais que mon drapeau reste sur la page 2? Quelqu'un a déjà fait ça?

vi  
tu associe le numéro du post dans le topic qui est lui même associé au drapo  
 
... me suis-je bien exprimé ?, j'ai comme un doute

en gros tu veux reprendre à la page ou on était avt les post suivants...moi aussi je sais pas comment gerer ca
je pensais ajouter le numéro de page en bdd mais c'est pas valable : si un membre supprime des posts...le numero de page peut etre erroné

c'est comme ca sur mon forum, mais je considere ca comme un bug, car quand je lis la page 1 le drapeau me revoie sur la page 1 la prochaine fois que je clique dessus
et c'est bien chiant car j'ai perdu le dernier endroit que j'ai lu

 
heu non  

je me disais aussi  
 
dans ta table de flag, tu met l'ID_topic, jusque là rien de surprenant
mais tu mets aussi un index de post (si tu as lu le 21 ème post du topic, tu stocke 21), ainsi si l'utilisateur clique sur son drapo, tu l'envoie vers la page 1 s'il a configuré un affichage en 30 post/page ou en page 2 s'il a configuré 20posts/page, ensuite tu te débrouille pour positionner à l'endroit du post avec des ancres qui vont bien  
 
c'est mieux là ? ou je fais un schéma ?  

c'est mieux mais reste tjr le pb que j'ai cité plus haut : si un membre vire des posts precedant ton flag...ca peut changer le numero de page : genre ton flag se retrouve en pg 1 et non en 2

euh, en effet

j'ai p'tet dis une connerie : si lorsque un membre supprime un post, on soustrait 1 au flag de tous les membres ayant accedé o topic...ca peut resoudre le pb  

ah ben oui tient

je viens d'y penser à l'instant...ai-je bien fait d'en faire part à tout le monde  
now vais pouvoir mettre en pratique ma théorie révélée au public  

trop tard, je l'ai implémenté en 1er  
 
 
nan, spa vrai, ça fait 1 an que j'ai pas touché à mon forum

toute facon on voit bien que je me suis basé sur ton idée pr résoudre le souci ayant pu en résulter...enfin on s'y est mis à 2, na!

certes, mais de là à ce que je le mette en place

moi p'tetre
mais vu le nombre de rows que peut retourner la liste des posteurs du topic pr faire un -1 sur un champ...ca va faire un p'tit lot de requetes
a tester    

ben non:
update table_drapeau set nb=nb-1 where id_sujet=$id_sujet
 
en une seul requete
 
mais bon, je ne vois pas sur quel champs vous allez faire -1

vi me suis trompé, une seule requete necessaire
 
 
avec une table t_flags du style
id_membre
id_topic
id_dernier_post(la on stock l'id du dernier post pr pointer dessus qd on a recup la bonne page)
numeropost (comme l'a dit the real smiley, un champ contenant la position du dernier post vu, c'est lui q'on soustrait)

Je viens de finire la suppression des sujets
Ceux qui l'ont fais comprendront ma joie ...  
 
dodo ZZZzzzZZZzzz...!

ca c'est une chose, moi chui en train d'integrer une sorte de corbeille pr repecher les topic effacés par erreur par les modos par ex

Et puis quoi encore une validation de la suppression et puis c tout !!!
Plus serieusement tu fais un champ visible que tu passe a 0 pour une pseudo suppression c ça ?

au départ je pensais faire une sorte de forum caché ou je stockerais les topic deleté mais finalement j'ai opté pr un champ supplémentaire en tant que flag. J'ai l'impression qu'il va falloir que je rajoute des corbeille=0 un peu partout dans les requetes pr pas visionner un topic deleté lol

 
La vache o_O. Donc en gros avant d'en arriver à la suppression du sujet, tu supprimes tous les messages grâce à une récursivité ?. Hum, je pense qu'il existe beaucoup plus rapide.
 
 

 
Idem. J'ai adopté cette solution qui je pense me paraît la plus courte et la plus rapide pour arriver à bon porc (huic huic ^^) Seul inconvénient, je dois passer par une table temporaire pour mettre à jour la table utilisateur. Voilà le code
 
 

Création de la table temporaire
 

Insertion dans cette table du nombre de messages posté par chaque utilisateur plus leur identifiant
 

Mise à jour de la table utilisateurs. Je décrémente le compteur global du nombre de messages pour chaque utilisateur.
 

je drop la table
 
Je pense après avoir écris ce petit compte rendu qu'il y a moyen de faire tout ça en 3 requêtes hum…
 

 
Une boucle et 1000 update, d'un coup o_O. Hum. Pour ma part je préfère moins de boucle mais plus de boulot de la part d'un SGBDR.

j'ai fais sans table temporaire
par contre j'ai evidemment bouclé (une requete par membre) sur l'update de la table des membres lors de la decrementation du nb de posts
 

DaFloodMachine remplit maintenant ma petite DB en 20 secondes
chuis sûr que je peux encore améliorer un peu le truc
(purée mais quelle merde c'était au début )

 
étant donné que ta table est temporaire, passe là en Heap, tu accélérera beaucoup tes perfs

Tu peux difficilement faire mieux. Si 1000 membres différents ont posté dans le sujet ca fait 1000 profils à mettre à jour quoi qu'il arrive. La solution d'une table temporaire est beaucoup plus gourmande pour le SGBD (subselect et surtout GROUP BY ... heu ).

 
J'ai p-e u une idée ... Etant donné qu'il est facile de classer les sujets par date, pourquoi ne pas fusionner dans ma table date et auteur? Dans le genre : date|auteur , pour l'extraire du db il suffirais de faire un MAX et apres un explode pour avoir les 2 champs.Ceci m'eviterais de devoir rajouter des champs supplémentaires dans lequels je mettrait la date et le nom de la personne aillant posté en dernier, quesque vous en penssez?

Je viens de faire ma gestion de vote mais j'ai fais un table choix plutot que de ne proposer que 10 choix inclus dans l'entité vote, qu'en pensez vous ?

GFreeman : l'utilisation de table temporaire peut poser probleme je pense :  
si 2 membres suppriment 2 topics en meme temps...ca risque pas de planter lors de la creation de la table?

La table n'a pas un nom fixe

bon, merci pour vos interventions sur les drapeaux
 
j'ai imaginé la chose suivante: dans ma table drapeaux, je stocke l'id de catégorie, l'id de topic, le numéro de page du dernier message "lu" et l'id du dernier message. Jusque là, je peux produire sans problème le même comportement qu'ici. L'astuce, c'est de stocker également le numéro de page le plus haut sur lequel l'utilisateur est passé. Si ce numéro est différent du numéro de dernière page, on se place au début de la page, sinon, on fait comme ici: on se place sur le vrai dernier message lu.
 
Qu'en pensez-vous?