Reprise du message précédent :
Question con pour les personnes qui ont fait des sous-cats : comment vous gérez cela au niveau de la BDD ?

Simplement par pure fainéantise Je n'avais pas envie de passer des variables à ma page header.inc.php pour générer la balise meta refresh qui va bien (d'où aussi la gestion des bans TT par un header location et non plus par un meta refresh ).

perso je la vois comme un filtre, rien de plus. J'ai donc une table qui liste les sous-cats, et chaque topic référence l'une d'elle. Je prévois aussi qu'une cat n'utilise pas forcément les sous-cats.

 
+1 en gros, c'est juste un filtre

Le problème est que j'ai prévu cela comme découpage :
 
Une première BDD va contenir les datas communes à toutes le configs de forums (users et leurs préférences, messages privées, supadmins, réglages généraux, réglages de chaque config). Une deuxième par contre va contenir les tables des messages de la config de forum sélectionnée (donc une table supplémentaire par config de forum) mais aussi la table des admins, celle des modos et celle des droits d'accès.
 
Mais mon problème concerne ma gestion des messages de chaque catégorie :

Mon problème est que j'utilise 3 tales pour une catégorie donnée (je cherche à diviser les données pour limiter le poids des données dans chaque table et aussi le risque de perte de données). Donc, je me retrouve avec une division arbitraire qui me fait m'interroger sur la façon dont je vais amener la gestion des sous-cats ...
 
En fait, je me demande si c'était une si bonne idée de vouloir ainsi diviser mes données ...

Je précise que ce n'est qu'un premier jet et que cela risque fort d'être modifié.

Pour ma part, je me suis finalement lancé dans une division aussi (par cat), mais la tables des sous-catégories reste une et indivisible

Intégrée dans la table des catégorie ? ou au même niiveau ? (tiens effectivement la deuxième option pourrait marcher ...)
 
Edit : par contre j'ai intérêt à faire gaffe à mes index moi ...
 
Edit bis > Voila qui devrait suffire je pense :
 

je vais revenir sur le problème des très longs topics. J'ai idée d'implémenter un truc qui ressemble au split, mais pas tout à fait. Je me suis demandé si ça ne serait pas mieux d'avoir une table associée à celle des topics, et qui définirait des bornes inférieures et supérieures pour un topic (premier et dernier id de message) pour former des intervales de disons 1000 messages. Et lorsque je veux voir un bout de gros topic, j'utiliserais ce filtrage supplémentaire pour accélérer les perfs. Bien sûr, il faudra éviter qu'un message puisse être effacé lorsque le cap des mille messages est passé. C'est exactement ce que je compte faire si je l'implémente tel que je l'ai en tête. Dès que j'ai fini d'archiver ma DB HFR-sized, je regarde ça de plus près

 
tu peux toujours taper un bout de javascript dans la page

Moi je verrai plutot un truc basé sur le temps séparant le postage du message (pas l'édit) et la demande de suppression ...

oué mais quand t'as des boulets qui floodent, ça te fait un gros paquet de messages à traiter. D'ailleurs en parlant de temps, j'ai remarqué un problème potentiel, après avoir changé mes ORDER BY (basés sur les ID plutôt que l'heure de postage): imaginons que je restaure un dump MySQL, il y a des trous dedans pour diverses raisons (topics ou messages effacés), bin MySQL va tenter de boucher les trous. Sisi. Du coup, je peux plus ordonner une liste de topics ou de messages par ID, je dois forcément utiliser la date

ça marche pas bien mon histoire, et en plus je ne comprends pas ceci:
 
soit la requête suivante:
 

 
pas de jointure, et les 2 champs spécifiés dans le WHERE sont indexés. Alors pourquoi les deux conditions sur la date n'ont pas d'influence sur le nombre d'enregistrement retournés? (71551, c'est un peu lourd)
 
en gros il me dit:
tblmesg_1 ref ixlmesg2,ixlmesg3 ixlmesg2 4 const 71551 Using where.
 
Qu'est-ce que j'ai loupé?

à mon avis ca peut venir de ta condition de filtre sur les date :  
vu que tu formate la date (format US vers Fr) dans la requete, utilise l'alias fldmesgdcre au lieu du champ tblmesg_1.fldmesgdcre de la BDD
 
PS : TimeStamp poowwa !! lol ->plus facile à manier  

 
Soit les messages ayant pour ID 5,6,7,8 et 9
 
Tu supprimes le message n° 7 :
 
DELETE FROM messages WHERE id = 7;
 
Puis tu en postes un nouveau :
 
INSERT INTO messages ([...]) VALUES ([...]);
 
MySQL va te le mettre à l'id 7 ? Si id est en auto_increment il aura nécessairement la valeur 10. Suivant ta version de MySQL la prochaine valeur de ta clef primaire en auto_increment est présente en dur dans les infos de structure de table :
 
CREATE TABLE table ( [...] PRIMARY KEY (id) ) TYPE=MyISAM AUTO_INCREMENT=10 ;
 
Mais je crois que ca n'est de toute manière pas indispensable, MySQL ne "bouchera pas les trous" même si cette info est absente de ton dump. Tu es sur de ne pas t'être planté quelque part dans tes tests ?

mysql selectionne le MAX et l'increment de 1 pour les id autoincrement, il ne peut pas reboucher un trou, il faut le faire manuellement

Je le pense aussi : pour moi, un champ en auto_increment voit sa valeur augmenter. Et les anciens numéros sont considérés comme "brulés" par MySQL. Même dans le cas ou tu supprime le dernier élément, cet élément est considéré comme ayant déja été utilisé.

En fait, j'avais procédé à un flood d'insertions dans la DB, mais je spécifiais moi-même l'id au lieu de laisser faire l'autoincrement. Mais l'ID utilisé dans mon code était unique pour toutes les tables, ce qui a forcément généré des trous. Puis quand j'ai testé mon forum, je poste dans le premier topic venu, et quand je suis revenu sur la page des topics, il avait disparu. En fait, il avait été relégué dans les dernières places parce que l'id du dernier message était inférieur à ceux qui le précédaient  Donc je me suis dit qu'il bouchait les trous (ce qui serait mal, dans le fond)
 
On va mettre ça sur le compte d'un draschebug et de la châleur

Essai de lire ta phrase a fond  

au lieu de mettre l'id du dernier message, tu devrais mieux mettre la date du dernier message.

 
mysqldump pour réaliser le backup
 
Et pour le restaurer je fais ca directement en ligne de commande (mysql < mon_backup.sql). C'est très fiable, même avec des bases énormes, mais c'est très long. Devinez combien de temps prend l'intégration d'une base de 4.5 Go sur mon Céléron 433 / 384 Mo de RAM / 20 Go Maxtor 7200 tours ?

maintenant que j'ai vu qu'il existait des hébergeurs gratuits C#/SQL Server, ça me donne presque envie de développer mon forum

 
Mais laisses tomber la qualité. Nombre de requêtes limités, plantages etc etc.

Je vous repose ma question que je vous ai posée il y a une page car elle as disparu
 
Quel est le moyen d'empecher quelqu'un de générer (grâce à un logiciel fait maison) un nombre important de connexions à la seconde à votre serveur web.
Le problème n'est même plus le code à ce niveau là, c'est le serveur je pense et donc est-ce la mémoire ram, le processeur, ou une configuration dans Apache qui pourrait limiter les accès d'une certaine ip ?
Merci d'avance

Je note merci .

tu ferais mieux de demander cela dans la cat software et reseau.

 

C'est simplement dans ta table physique qu'il bouchera les trous, une sorte de défragmentation, en gros tu auras :
 
ID 1
ID 2
ID 3
ID 4
ID 5
ID 6
ID 10
ID 8
ID 9

Drasche ca a résolu ton probleme de requete? j'ai pas eu d'echo lol

euh ça je le fais hein, sinon bonjour les jointures pour afficher la date en question

En fait j'utilise le format universel (année-mois-jour) et MySQL me l'affiche tout pareil
 
Mais je suis en train de bricoler un truc pour voir si je peux pas avoir un sévère gain de perfs quand je consulte un gros topic, quelque soit la page

Je suis en train de recommencer mon forum de A à Z  

Dans mes champs datetime, j'ai prévu de stocker mes datas sous la forme '00-00-0000 00:00:00'. Je me demande si c'est une bonne idée ...

en fait lors du restore, faut penser à virer tous les index et les recréer ensuite, ça accélère déjà pas mal la chose il me semble

comment faites vous, sur des topics de centaines de pages, pour alléger la charge au niveau DB quand vous voulez visionner la dernière page? (parce qu'une bête requête avec LIMIT, ça va bien un moment)
 
J'ai imaginé un truc pour alléger la charge, non seulement sur la dernière page, mais surtout, pour que les perfs soient sensiblement équivalentes, quelque soit la page que vous visionnez (je viens de tester mes requêtes sur un topic de 3000 pages)
 
Pour cela, j'ai ajouté un champ spécifique dans la table des topics, et un autre dans la table des messages. Je l'ai temporairement baptisé lock id (faute de mieux, j'aurais pu employer le terme "page" mais ça va pas pour des raisons évidentes Bien que... )
 
On peut en fait faire une analogie avec les pages. Mettons qu'une page comporte 25 messages (chiffre arbitraire, mais peut avoir un impact sur les performances).
 
Lorsque je débute un topic, je suis en page 1. Chaque message reçoit donc un lock id de 1, et ce même lock id est stocké tel quel dans le row correspondant de la table des topics. Lorsqu'on arrive à 25, hop, on incrémente le lock id: page 2, lock id = 2. Jusque là, c'est simple.
 
Mettre un truc pareil en place impose quelques contraintes: lorsque le lock id d'un message est inférieur au lock id du topic, il ne peut être effacé (et du coup, je pense en interdire la modification également). Du coup, ça ressemble aux splits, mais on n'en voit rien visuellement L'autre grosse contrainte, c'est un lock de la table sur les inserts, le temps de faire un select count (qui prendre 25 rows maximum) et l'insert suivant (et éventuellement un update sur la table des topics).
 
J'ai peur qu'à la fin, ça soit un peu lourd pour un simple post de message  Qu'en pensez-vous? Des question?

Le SELECT COUNT(*), même sur des millions d'enregistrements est ultra-rapide normalement

 
c'est un peu chiant ca
imagine le dernier message de la page 2 est un message avec des insultes dedans etc.. direct une réponse plus tard, on passe en page 3, et le message n'est pas effacable .. ?

j'avais pas pensé à ça

 

 
par contre tu peux peut etre garder 2 ou 3 pages d'avance avant de locker ..

ou alors je fais le vrai split comme Joce l'a fait mais ça me plait pas

en fait j'ai dit 25 mais j'aurais pu dire 1000 pour faire comme le vrai split d'antant

Les splits d'antant étaient quand même éditables par les modos