Reprise du message précédent :
Pour gérer le design j'ai tenté un full-CSS, mais en fait je crois qu'une bonne vieille <table> convient mieux. Vous êtes plutôt quoi?

Si tu affiches un index de forums ou de sujets, table. Si tu affiches une suite de messages, divs.

Ok merci
 
Et sinon pour le spam? Pour le moment j'ai un reverse-captcha + validation par email. Vous avez quoi en plus? Des regexp pour détecter les mots? Mais ces raclures font leur propre anti-regexp avec V!@gr@ ...

Encore une question: pour la zone admin vous l'avez séparée complètement de la zone publique ou bien vous avez des liens avec des if admin? qui renvoient sur la même page d'édition que le publique avec des options en plus?
 
Je serais plutôt partant pour mélanger public/admin étant donné que ça va énormément se ressembler.

Quand un user loggé poste un message sur un topic, ça représente en tout combien de requêtes sql entre les select, insert et update? Perso j'en suis déjà à 9  

oui, rien d'étonnant à cela
Je dois en avoir facilement le double

Ok ça me rassure, j'ai encore un peu de marge sous le pied  

Hmm. Sur la page d'index d'une catégorie comment faîtes-vous pour 'joindre' la table topics et la table flags?
 
J'ai tenté avec une seule requête et des LEFT JOIN comme je l'avais imaginé mais ça ne marche pas car quand je rajoute un WHERE flags.user_id = 12, et bien ça m'enlève tous les topics qui n'ont pas été flagé par le user. Alors c'est bien pour la page 'listes mes topics suivis', mais pour la page d'index général ça ne suffit pas.
 
Il faudrait donc d'abord faire un select de la liste des flags d'un user, et ensuite la joindre sur la table des topics. Donc 2 requêtes en fait. J'ai bon?

LEFT OUTER JOIN peut etre ?

D'après: http://en.wikipedia.org/wiki/Join_(SQL)#Outer_joins
 

C'est vrai ça? Dans ce cas là je garde mon inner-select (parce qu'il marche et j'ai le contrôle de son where avec un côté 'optionnel'). J'avais tenté avec LEFT JOIN (qui je crois est équivalent au left outer join), mais si jamais un topic n'a pas de flag il ne sera pas sélectionné dans la liste.
 
EDIT: Pour la table des flags, j'ai vu que vous limitez le nombre de flags par membre (c'est normal), donc j'ai implémenté ça de la façon suivante:
Solution 1) max 20 flags par membre. Si membre poste un nouveau message, alors chercher combien de flags il a. Si >= 20, alors récupérer le plus vieux flag et le recycler pour ce nouveau message (si un flag n'existe pas déjà pour le topic). Ensuite on fait 1 jointure pour trouver la liste des flags et si un topic a été updaté depuis.
 
Solution 2) flags illimité par membre. Par contre en récupérant la liste des flags pour un membre, d'abord faire un inner-select avec LIMIT 20, et ensuite joindre cette liste à la liste des topics. Ca fait 2 requêtes pour afficher la liste, mais ça évite d'updater la table user pour compter son nombre de flags et ça évite d'updater la liste de ses flags lorsqu'il en a 20, car un INSERT est plus rapide. EDIT: le gain sera naze au début, par contre la DB va exploser ça c'est sûr.
 
Vous utilisez quelle solution? Une autre?

Pour la gestion des sujets lu / pas de nouveau message depuis dernière visite, ça ressemble aux flags, peut-être plus facile à mettre en place, par contre la DB va devenir gigantesque. Vous nettoyez de temps en temps ou bien la jointure est finalement assez légère puisqu'on travaille sur une liste de sujets réduits et la DB n'a qu'à chercher parmi une petite liste à joindre?
 
Sinon il y a un code source de forum dispo et assez propre où je pourrais jeter un oeil? C'est dommage que le topic ne soit plus trop à jour, plusieurs forums sont inaccessibles et les sources aussi.

En fait pour le système de drapeaux, il n'y a pas besoin de limiter leur nombre par utilisateur, car quand l'utilisateur fait sa recherche il suffit de faire de la pagination et un LIMIT comme ça on se retrouve pas avec une liste de 200 topics.
 
D'ailleurs je viens de voir que md.net ne limite pas les drapeaux rouges (le sujets lus). Avec les bons index, il ne doit pas y avoir de pertes de performance quelque soit la taille de la table (je suppose).
 
EDIT: au pire un peu de maintenance annuelle où on déplace les vieux topics et les flags associés.

Ca y est j'ai implémenté un système de 'flags' comme sur hfr qui permet de suivre les topics qu'on a déjà lu (topic_reads) et les topics dans lesquels on a posté (topic_subscriptions). Il existe 2 solutions à ma connaissance pour joindre toutes ces tables entre elles, donc laquelle scalerai le mieux selon vous?
 
(J'ai viré les paramètres qui n'apportent rien au problème)
 
Solution 1) Avec des inner-select / sub-select.
Crade
 
Solution 2) Double jointure sur la table topic_subscriptions et topic_reads
Encore pire
 
Solution 3) Autre?
 

 
Perso je trouve la première plus lisible, surtout que je peux y ajouter LIMIT sur chaque sub-select, alors qu'avec les double jointures le LIMIT ne sera qu'à la fin. J'utilise Postgresql si ça peut aider à choisir.

Le plagiat avoué !
C'est un coup à avoir un procès au cul ça

J'ai utilisé le terme flags ici, mais sur mon forum, j'appelle ça des 'coeurs' . L'idée de suivre un topic n'est pas déposable   , et de toute façon ça ne répond pas vraiment à ma question  

Navré de pas répondre a ta question, juste que je comprend pas pourquoi tu fait une double jointure sur tes tables (ts/ts2, tr/tr2), ça te sert à quoi ?

faudrait d'abord qu'il soit l'inventeur de ce systeme, mais apparement, il a pompé l'idée et meme l'image du drapeau sur outlook    
 

 

 

 
a moins que ca soit microsoft qui ai copié sur joce ?  

Outlook s'pas un forum

D'un autre côté faut bien reconnaître que MD est l'un des rares forums avec des "flags" qui fonctionnent et servent à quelque chose

EDIT: en fait je tapais nawak...
 

+1, y'a plein de forums où c'est carrément pénible de suivre des topics ou alors il faut se prendre la tête à s'abonner à un topic en 10 clics, super lourd... T'as aussi ceux qui se font pas chier sur les nouveaux messages depuis la dernière visite, si last_visited_at > 5 minutes, hop tous les topics apparaîssent comme lu  

"Et d'après ce que j'ai recherché, si jeux rajouter une condition sur la jointure, càd LEFT JOIN ON topic_subscriptions.user_id = 5 il faut que je double la jointure"
 
T'as mal cherché
 
Tu fait un seule jointure :
FROM truc t LEFT JOIN machin m ON (t.id = m.id AND m.user= toto)

 
 
En fait je tapais: FROM truc t LEFT JOIN machin m (ON t.id = m.id AND m.user= toto)
 
Grand merci  

Je vous présente vite fait la dernière version de mon forum :
http://forum.free-bb.com/dev2/?sid=1
 
Il manque encore pas mal d'options mais cela donne déjà une bonne idée de ce que sera la version définitive.

C'est très bien. Par contre le lien de la liste des membres ne marche pas : http://forum.free-bb.com/dev2/memb [...] only&sid=1
 
EDIT: y'a des signatures qui sont pas un peu abusées? Certains posts sont illisibles.

pos = textarea.selectionStart

?

il fait le café ?

Question à Joce ou à toute personne qui développe des applications multi-site. Est-ce que vous utilisez la même BDD pour tous les sites avec par exemple un site_id pour filtrer, ou bien vous avez séparé les BDD?

Et ton application tu la dupliques pour chaque client? Ou bien c'est une seule appli capable de se connecter aux différentes DB en fonction du besoin? Si c'est le cas au niveau des connections à la DB tu gères comment? Tu ouvres et fermes pour chaque requête ou groupe de requêtes?

Niveau synchronisation des db en cas de migration, tu fais comment ?
Et les db tu les crées à la mano ou c'est un truc un peu plus transparent ?

Sinon perso pour mon shop multi-sites j'ai une seule db avec filtrage sur shop_id. D'abord parce que je sais pas faire autrement sans emmerdes et ensuite parce que j'ai une admin générale et des stats sur l'ensemble des sites.

Mais c'est pas encore en prod.

Non pour l'instant ça me va très bien
Et au besoin je lirais la doc de Doctrine sur les configs alacon et les migrations avant de t'embêter

Idem, une seule BDD pour 52 000 forums

Salut,
 
Pour gérer la liste des sujets d'une catégorie, j'utilise un système de positions pour éviter de faire des LIMIT qui sont très gourmands.
Les sujets sont ordonnées selon la position 1, 2, 3, 4... Quand on poste sur un sujet, cela remonte le sujet et donc je mets à jour les positions.
 
Exemple :
Sujet A - Position 5
Sujet B - Position 4
Sujet C - Position 3
Sujet D - Position 2
Sujet E - Position 1
 
Je poste dans le sujet C, ça devient :
Sujet C - Position 5
Sujet A - Position 4
Sujet B - Position 3
Sujet D - Position 2
Sujet E - Position 1
 
Tous les sujets plus récents que C prennent -1 et C prend la position maximale. (pour simplifier)
 
Mon gros problème est que quand je remonte un vieux sujet, je dois faire -1 à parfois 2 000 sujets. La requête étant bloquante, tous les sujets restent inaccessibles. Si par malheur, ce qui arrive souvent, un autre visiteur poste en même temps sur un sujet plus récent que C, je me retrouve avec une magnifique deadlock sur la bdd.
 
Avez-vous une méthode miracle pour ça ? Comment améliorer le système ? Utilisez-vous carrément une autre conception ?
 
Merci !

J'ai gardé la solution du limit avec un index sur la colonne 'date de dernière réponse' et un order by date.  
Je suis parti du principe que les pages les plus récentes sont les plus souvent vues, ça fait des limit 0,20 ou 20,20 la plupart du temps et la requête reste globalement acceptable.
 
Une idée (pas forcément applicable) si tu veux garder ton principe de position, tu ne renumérotes pas tes positions mais ne fait qu'incrémenter à chaque fois. Ca donnerait donc  en répondant au C :
Sujet C - Position 6
Sujet A - Position 5
Sujet B - Position 4
Sujet D - Position 2
Sujet E - Position 1
la position 3 est "perdue" mais tu évites le lock de ta table. Et pour être propre, de temps en temps, tu peux passer un script à une heure de faible charge pour faire la renumérotation des positions et boucher les trous