Reprise du message précédent :
C'est ptet par le meilleur endroit pour demander ça mais on ne sait jamais : Est-ce quelqu'un aurait une liste de stopword pour le français (pour utiliser avec le fulltext de mysql) ?

 
qu'est-ce que tu appelle stopword ?

http://library.wur.nl/isis/docum.txt multilangue, dont le francais, pas exactement ce que tu veut, mais c'est déja ca ...

merci, il est un peu court (pour le français) mais c'est déjà un début

suffit de rajouter la variable id_forum=id dans l'url  

oui, sinon avec 4000 forums, sa me ferait un sacré ftp balèze !!!

 
   
 
si tu veux tu crées une BDD par forum, mais ca sert strictement à rien de copier les fichiers php  

par contre, avoir 4000 bases, il gere ca comment mysql.

il gère pas
Oracle roulaize

Tu ne crée pas de nouvelle base mais tu recopie les tables  necessaires avec un préfixe connu qui les identifira a tel ou tel forum ...
mais la base restera la meme, sinon il faudrait un fichier de connexion différent par forum

on en avait fini avec ce HS

Et ce forum en asm, ça avance?

Ca risque d'être relativement ingérable
 
Mettons seulement 5 tables/forum (Et encore, c'est très très peu, tu vas sûrement en avoir le double ou le triple). Ton forum gagne à être connu, tu en as créé 1000.
 
Ca fait au total 5 000 tables. Je ne pense pas que l'on puisse se rendre compte de l'ampleur du truc
 
Pis c'est assez stressant de ne jamais savoir combien de tables tu auras si elles montent avec la création de forums. Il vaut mieux, à mon avis, avoir un truc assez carré
 
PS : Prends l'exemple de Limit (Webmaster d'AceBoard) qui hébergent plus de 100 000 forums Ca te fait très facilement 500 000 tables ... voire 1 000 000 ; ingérable

Oui Max c'est vrai que ça fera bcp de table et qu'au final cette méthode n'est pas la bonne, mais ce qui m'ennuis avec la méthode de tout mettre ds la meme table avec un champs pour différencier le forum, c'est que le mec qui a un petit forum de 100 topic sera pénaliser niveau temps d'accès par l'autre qui a une usine à gaz car ils auront les mêmes index etc ...
A mon avis il faut appliquer la méthode que tu dis et pouvoir si le forum dépasse 1000000 post (chiffre approximatif) passer à ma méthode mais uniquement pour ce gros forum ...

si la structure de ta table est bonne, il mettra autant de temps que tout autre forum.

skylight > plus une table est grosse plus l'index est gros

 
 
Comment faire pour avoir des temps constants quelque soit la taille ?

Ce n'est pas pour ça que parcourir l'index prend significativement plus de temps (sur une recherche, ça prend quasi rien en plus)

faut optimiser tes requetes et la structure de tes tables  

il faut surtout bien placer ses indexes (je le dis parce que j'ai peur qu'en parlant uniquement de structure de tables, on oublie trop vite cet aspect)

 
Pour un truc très basique, tu dois même pouvoir avoir qu'une table pour les messages...
Après ça dépend de ce que tu veux faire, hein...
 

 
 
c'est sûr que plus le serveur est gros mieux ça tourne, ya pas de miracle hein...
 

 
n'importe-quoi.

Spour ça que le p4 ça accélère l'internet

 
C'est là que je demande un exemple de la méthode "basique" et de la même chose "optimisée"

tu veux pas 100 balle et un mars aussi ?

Moi je voudrais bien un exemple aussi

Passer ses tables en format FIXE et pas DYNAMIQUE

ben ya du boulot hein
pis en plus, ça va bouffer de la place, j'en sais quelque chose

Tiens j'ai une question là comme çà. J'ai fait des mesures de temps d'execution pas à pas sur mes scripts avec les temps intermedaire. Et je me rends compte que les includes consomment enormement de temps. Selon, est-ce l'ouverture du fichier qui est longue? Ou l'interpretation du code? Car dans le premier cas, je me vois bien charger les fichiers en memoire vive pour gagner du temps.

Charger les fichiers en mémoire vive, c'est l'os qui doit s'en occuper.

Je sais que c'est l'OS. Mais je cherche à savoir ce qui est le plus long, l'ouverture ou l'interpretation.

L'intérprétation je suppose. Je vois mal comment il pourrait en être autrement.

Les accès disques, c'est très très lent.

C'est bien l'ouverture qui est longue
 
Page test.php :
<? echo "Bonjour bonjour bonjour"; ?> Répété 150 fois.
Temps de génération = 0.0002s
 
Page test.php :
<? include ("test2.php" ); ?> Répété 150 fois.
Test2.php contient <? echo "Bonjour bonjour bonjour"; ?>  
Temps de génération = 0.008s
 
Page test.php :
<? include ("test2.php" ); ?>
Test2.php contient <? echo "Bonjour bonjour bonjour"; ?> répété 150x
Temps de génération = 0.0004s

C'est notamment sur ça que travaille les accélérateurs (Turck MMCache & co)

Je suis bien d'accord mais je suppose que les fichiers qu'il includes sont ouverts relativement couramment et qu'il a une gestion de buffer cache digne de ce nom.

Tu veux prouver quoi? qu'en faisant des includes pour exécuter une ligne n'est pas spécialement intelligent? Ca on s'en serait bien douté. Un include n'est pas gratuit, on s'en doute aussi.
 
Ps: je viens de remarquer que le style semblait agressif alors qu'il ne se le veut pas (rajout smiley)

Ouais, et quand t'as un champ TEXT, j'demande à voir comment tu fais ...

  On demande si la lenteur de l'include vient de l'interprétation du code ou de l'ouverture du fichier. Je crois que ça le montre bien.
 
EDIT à la suite de l'EDIT : Ha, autant pour moi alors

Bah tu fous dans une autre table, j'sais pas

Tu ne supposes pas forcément bien!

Non mais qu'on s'entende bien, la lenteur de l'include ne provient pas du fait qu'il faille lire le fichier sur le disque. Donc ça vient d'où la lenteur, du parsing et des autres trucs du genre.