Reprise du message précédent :

 
 
ah oui ca doit etre ca la bonne méthode  

Toutafay    
 
D'ailleurs, pour ceux qui, comme moi, utilisent les cookies pour l'identification, n'oubliez pas de faire un mysql_real_escape_string sur les $_COOKIES, il est tout à fait possible de faire une injection mysql par les cookies, j'ai testé, ça fonctionne, donc attention quand même.

 
 
 
et $_REQUEST ?  
 
et sinon, moi oui, je ne programme qu'avec toutes les erreurs, notices incluses.
ca permet de lever un doute sur une faille potentielle.

idem. j'affiche toujours tout sauf pour le serveur de production où là, je baisse les infos affichés.

Comme tous les serveurs en prod, j'imagine.

Re, euh dites moi est ce qu'une bonne âme pourrait me mettre cette requête avec des jointures MySQL, parce que j'ai encore un peu de mal, et ca me donnerait un bon exemple... S'pour le regroupement des topics dans lesquels l'utilisateur a posté...
 

Voila ce que moi j'aurais mis
 

Tu veux les topics dans lequel l'utilisateur a posté, logiquement tout viendra de cette table, je la laisse dans la clause FROM
 

Si y'a des lignes dans last_read_post qui n'ont pas de lien avec cats, elle ne seront pas retournées (contrairement à LEFT JOIN)
 

Idem ci dessus pour le INNER JOIN
J'ai mis la comparaison sur le timestamp dans le ON car elle concerne la table FROM et la table jointe, ça a logiquement plus ca place ici que dans le WHERE
 

Ca ça n'a rien a voir avec une jointure, ça reste dans le WHERE, le ORDER ne change pas

Okay, merci beaucoup de ta réponse, j'essayerais lorsque je le pourrais
 

bonsoir tout le monde
 
je suis en train de tester plusieurs solutions pour optimiser les gros topics et la seul solution simple que j'ai trouvé, c'est de mettre le numero d'ordre du message dans le topic, remplacer le limit en quelque sorte.
Mais le probleme, c'est qu'en cas de suppression de message il faudrait mettre a jour les autres numero d'ordre, et ca risquerait de ramer s'il y en a 10 000 ou 100 000 dans le pire des cas.
Il faudrait pour palier a ce probleme, autoriser de supprimer seulement les plus recent, ou tout simplement d'interdire la suppression.
Vous en pensez quoi de cette solutions? en avez vous trouver d'autre ?

bah regarde ici, il y a des gros topics et tu peux supprimer n'importe quel message non?

tu connais la solution qu'utilise joce pour optimiser ce genre de topic ?
et je ne crois pas que joce utilise la methode que je decris plus haut.

Ta méthode est quand meme contraignante de ne pas pouvoir supprimer des anciens topics. Que fait tu des mass deletes?

Est-ce que c'est dérangeant d'avoir des trous dans les numéros d'ordre ?
 
Tu dis que tu veux les 30 premiers messages après le message n°9856 par ex. Même si les messages 9857 à 10000 ont giclés, ça devrait pas poser de problèmes, non  
(bon, faut que le reste de la table et le reste de la requête soit bien foutu aussi )

ben ca ne marche plus si des messages inferieur au n°9856 sont supprimé
 
 

c'est quoi ta methode toi ?

Ouais, en fait, ça mache que quand tu accèdes au messages de manière séquentielle (page 1, page2, page3, etc.), mais tu peux pas sauter directement à la page 3 comme ça, c'est vrai

 
C'est comme ça que je fais : mais pour les supressions je mets un flag sur les topics et je les garde en BDD, et à l'affichage je marque que le message a été supprimé.
 
Inconvénients :  
- Risque d'avoir des pages de "Ce message a été supprimé"
- Ca reste en bdd, ça prends de la place
 
Avantage :  
- Ca permet aux modos de lire les messages supprimés en cas de pb
- Et aux utilisateurs d'annuler la suppression
 
Mais bon, je suis toujours à la recherche de la solution miracle

Si je me souviens bien, Joce, il découpe les énormes discutions en lot de 25 pages et tous les 25 pages, il recommence un nouveau topic marqué comme la suite de tel autre.

nop, ca fait longtemps que j'ai abandonné ce système

 
ha oui, les splits c'est fini
 
Bon, joce tu fais comment alors ?    
 
tu va pas emporter ton secret avec toi dans ta tombe ?  

à mon grand désespoir

D'ailleur, le mass delete est vraiment une action trés trés rare, dans quel cas tu veux l'utiliser ?  
en cas de flood ? ca veut dire que t'es mal protégé contre le flood.
en cas de punition? ne plus afficher le contenu des message ca suffirait.
en case de demande d'un membre ? suffit juste de vide ses postes et non pas de les supprimer.
Mais bon, le mass delete c'est trés lourd comme action, faut mettre a jour plusieurs topics si tu garde en cache le nb de reponse du sujet.

ton bot s'ennuie ?  
 
edit: quelle époque quand même

Bonjour à tous!
 
Je développe mon forum depuis plus de 2 ans maintenant (en dilettante en majeure partie, mais beaucoup plus sérieusement depuis 2 mois). je me suis cassé un peu les dents aussi sur ce problème de performances à l'affichage des topics... J'ai retenu la solution de l'indicateur de position, redoutable d'efficacité à l'affichage. Je suis parti du principe qu'on efface rarement un très vieux message ou un très vieux topic: en effet, si besoin d'effacer il y'a, l'action est souvent menée très rapidement par les équipes de modération. Et le coût d'un update pour réorganiser les quelques dizaines (même centaines) de posts créés après n'est pas significatif. Enfin, voilà, j'ai adopté cette solution en attendant d'en trouver une meilleure!

imagine cette solution sur le topic MOARD de ce forum, ça doit faire mal à la base quand même non ?

 
En même temps ca fait mal pendant 3 secondes et tout le reste du temps c'est rapide nan ?
( j'ai pas trop d'ordre de grandeur du "ca fait mal" que ca donne en fait ... )

 
Oui et non... Imaginons la situation:
On a un topic de 14950 posts (au pif ). Le membre "Marcel" crée un post, qui aura la position 14951. 49 posts sont créés à la suite du post de Marcel. Un méchant modo Belge (toujours au hasard! ) décide de déléter le post parce Marcel à traité les participants de gastéropodes gluants analphabètes. La requete de réordonnancement des posts portera donc sur 49 enregistrements, ce qui n'est pas si terrible que ça... Bien évidemment, on part toujours du principe que les messages effacés sont souvent parmi les derniers postés. Et dans le pire des cas, à savoir qu'un post datant de juillet 1870 doit être supprimé, on peut mettre en place une solution qui remplacera le delete par une simple modification du post. C'est comme ça que j'ai procédé, en tout cas.

Ouais mais si au lieu d'effacer le n°14951, quelqu'un décidé d'éffacer le n°10 ?

d'un autre coté, faire un update pour decrementer un compteur sur 15 000 messages, ca ne va pas tuer un serveur.
 
Le plus contraignant est le mass delete, où l'operation va devenir tres lourse, surtout si le membre est tres actif

Selon mon procédé, le message sera édité parce que trop ancien pour être supprimé à moindre cout en ressources. La solution que j'ai adoptée n'est pas infaillible, ni même certainement la meilleure (c'est pas Joce ou Core666 qui me contrediront, on attend vos astuces les mecs! ), mais elle part quand même de la constatation que les messages supprimés le sont peu de temps après leur création dans 99% des cas, ce qui minimise les ressources nécessaires pour la réorganisation des topics.
Mais bon, ça m'empêchera pas de plancher sur une meilleure solution une fois que j'aurais fini de développer les features plus importantes!

Effectivement, les suppressions les plus nombreuses interviennent à la fin des sujets. Mais, il est regulier que certains suppriment de vieux messages pour faire descendre les nouveaux et obtenir le 'split'.
 
Pour le mass delete, rien empeche de masquer temporairement les messages du membre et les supprimer plus tard lors d'une charge moins importante. Ce n'est pas bien grave si les positions ne sont pas correct durant un laps de temps. Ca n'affectera qu'une page.

Certes, mais point de split en ce qui concerne mon forum! J'ai une seule table pour les topics, et une pour les réponses...

quand je parle de split, ce sont les pages comme 100, 500, 1000 où l'on s'amuse à supprimer des msg pour etre le premier msg de la nouvelle page.
 
Sur le mien, j'ai autant de tables de msg que de categories.

Et tu gère comment le déplacement d'un topic entre deux catégories ?

Je ne gere pas. Je ferme le topic

Le déplacement de topic ne pose pas de problème, puisque la numérotation des posts d'un topic est propre à ce topic, et que la table des topics et celle des réponses sont séparées. En fait, je gère 2 possibilités de déplacement
 
1. déplacement d'un topic en conservant le topic d'origine (un peu plus complexe, mais plus facile à suivre pour les membres)
- on crée un clone du topic et de ses réponses dans le forum cible, les numérotations de réponse sont conservées
- on insère un post en fin de topic contenant un lien vers le topic déplacé.
- on ferme le sujet
 
2. déplacement de topic simple
- on change simplement le n° du forum auquel le topic appartient, tout ce qui concerne les réponses est inchangé puisque indépendant du forum dans lequel se trouve le topic.
 
Après, y'a juste une histoire de mise à jour des informations statistiques des forums (nombre de topics, de réponse, etc...).
 
[EDIT] m****, c'était pas à moi qu'on parlait...

D'un autre coté, si tes categories sont bien pensées, y'a pas raison que le type se plante de cat. Je pourrai me faire chier à mettre en place de quoi deplacer le topic. Honnetement, je prefère le fermer.
 
Je me pencherai sur le problème bien plus tard.

bon je pense avoir trouvé la solution miracle , il me faut juste que je la test
 
je donne juste un indice: split invisible.

Faut une table du type N°topic | N° de split | nombre de messages . Maintenant si Joce avait fait ça, il aurait pu fusioner les vieux split facilement je pense, mais il ne l'a pas fait.

Salut tout le monde,
pour mon correcteur d'orthographe, je me suis penché sur plusieurs solutions, et j'ai découvert Aspell (librairie pour un correcteur d'orthographe) et sa déclinaison pspell, pour PHP.
 
Le problème c'est que ce mod s'installe avec php,
je cherche donc si il existe une classe qui fonctionnerais sur la même base, pour que je puisse redistribuer mon forum pour n'importequel serveur.