Bon, je viens d'installer un script (http://www.php-stats.com/ magnifique systeme de stat !!!!)
et je vois un truc, qui est franchement pas bete, sur beaucoup de forum, on peut optimizer les tables du forum, mais la plus part des webmaster ne le font pas, dans php stat, sur la page d'accueil, il y a directement l'etat des tables, et donc, ca fait comme un petit memo...

Bon, je parle pas de le mettre maintenant, mais, voila, je trouve l'idée tres bonne, alors je voulais le dire !

Oui l'idée peut être intéressante, à voir...

en gros tu affiche la taille de chaque tables ! ça peut-être bien !

Oui, ca peut etre bien, pour plusieurs choses, comme par exemple, beaucoup d'hebergeur gratuit/allopass conseil une db de 10 mo (apres ca ralentira)
je me suis faite avoir avec ma regie pub, ca faissait 2 jours que le site etait ralentit, en voyant les tables sur le systeme de stat, ca ma fait penser a tout verifier, et qu'est ce que je vois, sur ma regie, une table de 10,8 mo (177 000 ROW et des poussieres )

une fois purger, le site avait une vitesse normal.

Donc oui, afficher les stat des tables, peut etre sympa, et puis, ca permet de voir reellement a quoi sert l'optimisation !

Bah, phpmyadmin en fait autant

LOL un db mysql de maximum de 10 mo après ça ralenti mais laissez moi rire...

un système linux peut gérer des fichiers allant jusqu'à 4Go et nettement plus suivant la manière dont vous configurez la bête ! (avec du reseifs on peu sans souci monter jusqu'à 100Go pour 1 fichier...), la limite théorique de MySQL est de 8 millions de téraoctets...

Le seul vrai problème pour les grosses bdd c'est qu'il est impossible de les récupérer via des appli php, car il faut plus de 30 secondes pr effectuer le dump... Il faut donc passer par le lancement de commande système pour le faire et vérifier que l'espace disque est suffisant pour l'accueillir.

Sur ce messieur @ ++

Je sais que mysql peu avoir de grosse db, mais j'ai dit ca :

Non, je connais pas de système qui permet de ralentir une DB si tu dépasses une taille. La bloquer oui pour pas qu'elle dépasse une certaine limite (quotas) mais la ralentir ça m'étonnerait.
Ce que tu as fais c'est simplement de recompacter la DB comme tu défragmenterais ton disque dur c'est tout. Forcément si ta DB était fragmentée ça va plus vite aprés.
Pour info la DB de coolforum.net fait environ 12Mo en ce moment... C'est pas plus long qu'il y a 6 mois où elle en faisait 8 car ormis le nombre d'enregistrements qui a augmenté (et pour 5Mo ça n'est pas vraiment perceptible) je n'ai que 50ko de pertes donc pratiquement pas de fragmentation

tout dépends du système de fichier aussi, un mysql sur du fat ou ntfs sera nettement moins fiable qu'un ext2/3, xfs ou autre FS journalisée et open

/mode troll on (masi bon, fallait que j'ouvre ma gu.... )

ouep, mais en UFS, c'est encore plus rapide !
Et ca depend aussi de la gestion de la mémoire de l'OS, donc a priori FreeBSD 5.2.1 est bon aussi la dessus

/mode troll pas beau off...

Sinon, ma table CF_posts fait un peu plus de 20Mo, et ca tourne nikel, sur un systeme RedHat GNU/Linux, donc bon. Franchement luce, sur ovh il y a de sacré serveurs ou les bases font quelques Go, donc a mon avis, c'est plus pour eviter une surcharge de requettes SQL ou de bande passante qu'ils disent ca...

heu... ovh ??? c'est l'herbergeur, qui conseil des bases de données à 30 mo, et si tu es par exemple à 80mo, on te balance sur un serveur pourri ? ou alors, il faut payer plus !

(recherche il y a plusieurs mois, j'ai expliqué le probleme avec ovh !)

un truc, pourquoi beaucoup d'hebergeur conseil une taille pour la base de donnée ???

malmok : c clair !