Reprise du message précédent :
oups edit foireux

j'ai pas compris le rapport avec phpbb dans ton dessin ? !

c'est juste un axiome

comprend pas ce mot et pas envie de chercher une definition a 3h du mat

http://fr.wiktionary.org/wiki/axiome

 
Scull> Ta solution parait interessante mais peut-être trop lourde à implanter ?

 
ça me semble bien lourd tout ça   N'oublie pas Scull, PHPBB CAY LE MAL    

Il doit aussi ètre possible de rajouter cette 3eme requète seulement si le topic fait plus de X pages. Perso je trouve pas ça trés dur à rajouter dans mon cas...

y a plus élégant comme méthode, parce que pour mettre à jour les marqueurs en cas de delete, ca fait un peu bricolage

Vas-y Joce, parle ou on te fera parler
 

Et bien justement, c'est que il n'y a pas besoin de modifier l'emplacement des marqueurs si tu delete. Puisque c'est en fonction du numéro de la page.  
Par contre ce qui peu foutre le dawa, c'est d'effacer un topic marqueur...

j'utilise pas ce genre de technique vu que quelque soit le nombre de posts par pages choisi par l'utilisateur la vitesse d'affichage est optimale
Mais y a des méthodes plus élégante pour mettre en place un système similaire à celui de scull

ba oui voire plusieurs

Et t'utilises quoi comme méthode alors ?
 
Scull > Oui là t'es mal barré

fouyaya, si tu savais

En MP vas-y

He bien la solution conçiste à faire des enregistrement à blanc de topic marqueur.  
Quand le mec poste sa réponse, et bien j'enregistre son message (valider=1), et je lui met au cul un autre enregistrement ou valide=2 (marqueur donc). MAis quand j'affiche le topic, j'affiche pas les valide=2
 
Comme sa tu peu pas faire de delete de marqueur    
 
Il n'y a pas de problème que des solutions

c'est bien crade tout ca

Wé à faire trop compliqué ça va pas être joli
 
Joce, ta méthode est vraiment simple ou c'est un truc alambiqué ? Quand on delete un post, y met à jour qquechose pour le nombre de topics affichés ?

juste une question con  
caylemal de faire where id_post > 248 limit 20
le limit va quand meme partir de zero ?

Non c'est pas crade
 
Je suis sur que Joce il utilise un système de splitage des topics avec une autre table qui indique les id des topic splitté

La question avait déjà été posée et il a répondu que non, me semble-t-il.

Alors il a acheter les sources à docteur Maboul, d'ailleur c'est pour cela qu'il ne poste plus... Il est partis en vacances le bougre
Maintenant que il a des actions chez MD

Personne ne connait un topic similaire à celui-ci où ça discute des techniques pour faire son forum chez les ricains ou autre ? Histoire d'avoir d'autres points de vue... A moins que les ricains s'embêtent pas avec ça et se disent que Vbulletin/IPB le font pour eux car j'ai déjà googlisé pas mal et j'ai jamais rien trouvé dans ce genre

Les américains ce serait plutot dans des newsgroup non ?

Y'a http://www.foruminsider.com/forums/ section Idea and Innovations, mais ils sont pas très actifs

merci pour le lien

Salut,
Un petit nouveau forum entièrement développé par moi :
 
http://www.skitour.fr/forum/
 
Je vais essayer de décrire ses fonctions de "base" :
- gestion des identifications membre/modérateur globale au site
- surveillance des réponses et des nouveaux sujets par mail
- recherche (titre, auteur, message)
- pages d'archives facilitant l'indexation par les moteurs
- interface d'administration
- affichage des sujets connexes
- recherche en XMLHttpRequest des sujets connexes lors d'un nouveau post
- fonction "citer"
 
 

ajouté

L'est sympa
 
Quelle est la méthode utilisée pour afficher les replys dans un topic (puisque c'est le sujet actuel ) ? Le gros topic de 74 pages un peu + loin dans ton forum n'a pas l'air de ralentir, m'enfin ç'est pas non plus très gros et on sait pas ce qui tourne derrière

Salut
 
ça a l'air pas mal, attention cependant aux failles SQL :
 
http://www.skitour.fr/forum/search.php?mbr=%22

Aucun cache Pas assez de RAM, pas de assez de tout

je crois que ce topic est la plus grosse communauté de developpeur de forum

Fabien > Wé surement
 
Tiens Max Evans est là, alors c'est quoi le truc ?

J'ai tout bêtement repris la technique dont on avait parlé
 
Chaque post a son ID_POST_INTRA_TOPIC si tu veux, et je fais un WHERE ID_POST_INTRA_TOPIC plus grand que x=30 par exemple et plus petit que x=60 ...
 
Enfin, me semble, ça fait tellement longtemps que je n'y ai pas touché ...

Wé le BETWEEN quoi (à savoir si c'est + rapide pour MySQL de faire id>x AND id<y qu'un BETWEEN x AND y car on a 2 conditions contre une avec le BETWEEN qui est surement optimisé pour ça ) et tu UPDATE les ID intra-topic à chaque DELETE d'un reply alors (t'as pas trop le choix t'façon ) ?

Yes voilà
 
J'ai testé sur le topic flood de 500 pages en deletant un post à la page 2 ...
 
MySQL occupe 20% du CPU pdt 4-5s ...

Ah wé quand même, en + l'UPDATE bloque la table pendant ce temps là normalement... Imagines un DELETE en page 2 d'un topic de 15000 pages ici, le CPU va mouliner 1 minute à tout UPDATER

Fort probable
 
EDIT : Ceci dit, ca doit pas arriver tous les jours qu'on delete un post du début ds un tomik immense
 
EDIT2 : Sinon, passer la requete en LOW_PRIORITY, j'sais pas ce que ca pourrait donner
 
EDIT3 : Nan c'est mort
 

Bah le LOW PRIORITY va attendre que personne ne lise la table, mais si y a beaucoup de connectés et vu qu'elle prend pas mal de temps, c'est mal barré pour les autres
Joce y doit pas faire comme ça, essaie encore

 
J'ferai peut-être des splits invisibles, un jour

M'enfin tu as quand même raison, le DELETE d'un reply très ancien sera rarissime pour ne pas dire inexistant, ça se fera sur les 5 dernières pages à tout casser donc l'UPDATE sera très rapide (disons 5*25 ID à corriger si 5 pages de 25 replys) et y a pas non plus de DELETE tous les 5 minutes donc c'est valable comme méthode pour moi . Le ratio vu/delete doit frôler les 99,99%