Reprise du message précédent :
Autant pour moi, 16679 catégories

 
ah, donc 17000 cat, pas 17000 tables...ouf!

Sans compter que avec son système, chaque catégorie et donc table possède ces propres table de sujets et de réponses ?

 
Je suppose...
Je comprends vraiment pas d'où peut sortir une idée aussi tordue, franchement!

mais pas du tout
j'ai un script sql qui est lu et balancé moyennant une modif pour que chaque nom de table reçoive l'id de la catégorie
 
skeye: dans mon cas, vu que je joue avec les locks, ça va alléger un brin la charge.

 
M'étonnerait que le gain justifie une telle horreur de conception.
Et aller lire dans plusieurs/toutes les cat à la fois risque de te ruiner les perfs par rapport à une version plus raisonnable.

backups, corruption de données, etc, ça limite si tu plittes les tables. (genre ici on perdrait SETI, ben on perdrait uniquement SETI )

Si on veut pas avoir de pb on fait des sauvegardes, on nique pas l'archi de la base.

Excuse-moi, je fantasmais tout haut sur la perte de la cat SETI

c'est pas le code l'important, c'est la structure des tables...

 
si tu pouvais m'ajouter aussi ce serait bien

THE REAL SMILEY il se relache
faut marquer dans le titre  
"\o/ bienvenue à e-deby \o/"

phpBB c'est que du bonheur, 8 tables pour rassembler un topic, c'est le top
 
Déjà que j'ai eu du mal à codé un forum sur la structure de phpBB, alors faire un script de conversion...

C'est pour cela que je demande combien de messages
 
Pour 650 message, c'est plus rapide de faire des copiers coller

je fais pas.... (pour 650 msg)

oui... et crois moi sa prend déjà pas mal de temps...
 
Va chercher la date sur tel table, puis l'id de la catégorie sur tel table, puis le text sur cet autre table ect....
 
Sa c'est juste pour le sujet bien sur, car apés faut faire pareil pour les réponses... Sans compter que il faut modifier les "id" à la mains... sinon sa suit pas derrière...
Pareil pour les id des posteurs...
 
Et sa à faire pour chaque fois....
 
Alors imagine faire un script qui fait sa tt seul...

 
Je l'imagine bien

Quelqu'un sait comment installer PHPACCELERATOR sur son serveur ?

www.nfrance.com

vois pas en quoi c'est une abhération d'avoir plusieurs tables par cat

 
+1

je l'avais fait une fois l'import depuis phpBB. pour le 309gti-club. la base est ce qu'elle est, mais y'a vraiment aucun piege, l'import se fait sans souci

En partant d'une table vide sa doit surement ètre plus simple que de le faire a partir de table de multi forums déjà bien remplis non ?

Les intégristes de la normalisation ont encore frappé
 
Une entité = une table (normalement).

par rapport à une conception traditionnelle ou qui respecte scrupuleusement une méthodologie, c'est en effet pas correct
 
dans un cadre moins théorique avec des contraintes moins "qui me font ch***" et plus réelle la par contre ca l'est

normal... online.net ???
 
Avoue t'es chez free.fr

ca n'a rien a voir le nombre de site sur le serveur. faut voir quels sont les autres sites sur le serveur, la puissance du serveur, si la base est sur le meme serveur que le site, etc.
Moi apparement il y a 1000 sites sur le serveur et pas de probleme de vitesse    

klr 30 site par serveur sa fait vraiment pas beaucoup !!!

Je crois avoir lu un responsable de free annonçant en moyenne 3000 par serveur il y'a un certain temps

oué enfin à vouloir tout normaliser, tu fous en l'air les perfs d'une façon très jolie
Faut savoir ce qu'on veut : faire des applis efficaces ou se branler sur la beauté d'une table et les jointures de 10km de long pour acceder aux données

a mon avis chez free il y a des gros clusters qui gerent des dizaines de milliers de sites.

 
Pas mieux, si l'on veut avoir des perfs, il faut savoir denormaliser. Mais à bon escient.

 
Style faire une jointure sur une table qui contient la liste des cat' va te flinguer les perfs irrémédiablement...
Qu'est-ce qui est mieux, se branler sur 1 milliseconde de gagnée à la génération de ta page, ou sur la logique de l'archi de ta base?
Parce-qu'après tu t'arrêtes où? Tu vas aussi coller une nouvelle table par sous-cat', tant que t'y es?
 

 

Si tu veux des perfs, tu as probablement un tas d'autres choses à aller voir plutôt que foutre en l'air l'archi de la base...

 
Faut pas etre aussi integriste. Qui ta parler de foutre en l'air l'archi de la base.  
 
J'ai pas compris ta remarque sur la liste des cat'.  

blablabla
J'ai cru aussi que ça marcherait très bien avec des jointures pour faire une belle page d'index de forum. Mais non. Il FAUT dénormaliser un minimum. Style la table des catégories contient les infos de dernière mise à jour, dernier utilisateur, compte, etc. J'allais pas faire un COUNT sur la table messages à chaque fois que j'ai envie de voir la liste des catégories quand même? (surtout que suivant ta logique, ça aurait été un count groupé par cat, sur une seule table, ce qui aurait immanquablement flingué les perfs, puisque obligé de lire la table dans son entièreté à chaque fois). Je prends l'exemple du COUNT mais il y a aussi la date de dernier message et compagnie    
 
Maintenant je ne nie pas que j'ai des jointures tout de même, mais faut pas pousser bobonne dans les orties surtout quand elle est en short (quoique c'est bon pour les rhumatismes )

Laisse tomber le COUNT(*) foireux qui prend énormément de temps dès que tu lui ajoutes un clause WHERE
 
Privilégie le SQL_CALC_FOUND_ROWS en même temps de récupérer le nom de tes champs par exemple, c'est un monstre de performances
 
Sinon, forum-auto utilise une table pour toutes ses catégories, et il marche vraiment très bien

ben perso j'ai un compteur de messages que j'incrémente à chaque fois donc je me casse pas le cul avec des count Ma table de catégories reprend les infos de synthèse dont j'ai besoin pour afficher ma page d'index principal, idem pour la relation existante entre chaque cat et ses topics. Vous faites ça aussi il me semble, non?

J'ai cru voir que c'était le cas (un jeu de tables par catégorie).

 

Il te faut une table par catégorie pour stocker ce genre d'infos?
Franchement, quand je lis ça, je me dis que c'est encore pire que je pensais...au-secours, quoi!
Une table des catégories, avec un champ pour le nombre de messages, un champ pour la date du dernier message, etc, ça te parait trop compliqué?
Soit tu es pas réveillé soit tu as vraiment un gros problème avec la conception d'une base de données hein là!

euh non t'as rien compris... je stocke les infos de synthèse dans une seule table: celle des catégories justement.