Le Mercredi, 9 Mars 2005 18.57, Philippe Strauss a �crit : ... > je n'ai jamais utilis� mysql pour des besoins pareils, mais arrive-tu > a �crire une seule requ�te SQL pour tout ce bazar? Oui. Si je cible bien mes requ�tes avec des tables correctement index�es les temps de r�ponse sont excellents (moins de 0.1 secondes), pour par exemple une requ�te comprenant une dizaine de tables recherchant un champ par table (comme dit avant aucune table n'a moins de 100'000 lignes, au max 10'000'000). Le "probl�me" actuel �tant des stats annuels 01 - 02 -03 - 04 pour beaucoup d'articles avec de la calculation (somme, compte,...). Je pourrais fragmenter en plusieurs requ�tes, mais si j'�vite le passage par la table temp. je gagne beaucoup de temps.
Pour la petite histoire, lors du choix de la base de donn�es en 2001, j'avais fait des tests de charge sur plusieurs syst�mes avec un HP netserver PIII monoproc + scsi 10'000 sans Raid. Passons les qualifications, au final il restait Postgre et Mysql. Mon coeur voulait Postgre (pour les fonctionnalit�s) mais les tests �tait clairement en faveur de Mysql (mont�e en charge, rapidit�,ODBC), les fonctionnalit�s sont venues plus tard ou arriveront (par exemple proc�dure stock�e). De plus j'ai pu �viter de coder la r�plication de serveur (qui existait en version stable chez Mysql). Donc contrairement � beaucoup de troll, Mysql g�re tr�s bien les volumes moyens (pas tetst� des bases en TB !) et sa stabilit� est exemplaire. Il me reste � comprendre le message 'Copying to tmp table ...' Pas d'activit� disque, pas de fichier temporaire, myst�re. En contradiction avec la doc. Blaise Vogel _______________________________________________ gull mailing list [email protected] http://lists.alphanet.ch/mailman/listinfo/gull
