Joce à écrit :  
 
"SQL Server se fait torcher par MySQL a config equivalente "
 
Voici un test réalisé par eweek :
 
La base matériel est la même, et le test consiste à mesurer le nombre de page générées par seconde et selon le nombre d'utilisateur depuis une appli web qui "tape" dans une database.
 
L'appli web est du PHP.
 
 http://common.ziffdavisinternet.co [...] 898,00.jpg  
 
 
Diantre, Mysql est au niveau de ORACLE !!! et les autres DB sont à la traine !!!    
 
 
Et y'a rien qui vous choque ?
 
Maintenant, laissez moi le temps de trouver un benchmark avec sur SQL serveur sur une appli  .NET utilisant des drivers ADO...
 
 
Trouvé !
 
http://common.ziffdavisinternet.co [...] 900,00.jpg  
 

 
C'est plus la même histoire là !
 
Alors les tests DB/web fait avec du PHP et des drivers ODBC à la ramasse, ça vaut queud  

ben PHP n'a pas besoin d'ODBC pour accéder à des bases MySQL donc ce que Joce a dit est valide: SQL Server se fait torcher.

de toutes façons, en fonction des tests et de ce qui est testé (quelle volume de BD, avec quelle technique de query....), les SGBD les meilleurs ne sont pas les mêmes!
après, chacun a sa propre expérience et sa préférence ...

J'oubliais de préciser qu'il existe un un driver .NET pour MySQL mais ils se sont pas donnés la peine de tester.  On n'a donc pas de comparatif fiable sur le sujet, voilà tout.  D'ailleurs je trouve que Ziff-Davis se laisse un peu aller au niveau benchmarks.  S'ils ne se donnent pas la peine de comparer, c'est qu'ils ont un problème non?

 
Le problème n'est pas de comparer tel ou tel système avec tel ou tel driver, mais bien de fournir un ensemble performant.
 
Visiblement, le résultat montre que PHP avec son driver Mysql est moins performant que ASP.NET / ADO.NET / SQLServeur.
 

 
Ben, ça c'est selon toi.
D'autres diront que l'important pour un SGBD, c'est d'offrir de bonnes performances quel que soit le système dans lequel il est intégré.
Bref, ça reste très relatif comme jugement !

 
Mouais... que les pers de ton SGBD soient stable sur un linux ou sur un windows, tu t'en fout un peu.
Ce que tu veux, c'est que ton serveur marche vite !
 
 

 
Ba non, si t'as un parc de Solaris ou d'AIX, les perfs d'un SQL Server t'en as un peu rien à foutre.
 
(bordel, mais qu'est-ce que je fous là à alimenter ce troll ? )

Quand je parle du système dans le quel le SGBD doit s'intégré, j'parle pas que de l'OS. J'parle aussi des éventuelles appli qui dialogueront avec ce SGBD.
Il peut très bien y avoir des appli Php, dans executables C++ (odbc), des JSP, ...
Un SGBD qui tourne bien avec tout ça, c un bel avantage aussi.

pardon?  vitesse prime sur stabilité?  Et depuis quand s'il te plait?  Moi je veux qu'il soit stable avant toute chose sinon c'est au coin.  Ca sert à quoi d'avoir un truc pas stable?  S'il plante, on perd du temps à dépanner et on bloque les gens qui utilisent le serveur.  Idem pour n'importe quel type de soft.  Si c'est pas stable, à quoi bon?
 
Cela dit il y a deux orientations dans le choix d'un SGDB: l'homogénéité dans une entreprise (par rapport à la manière dont on le programme par exemple, chacun sait qu'un serveur SQL ne parle pas exactement comme un autre).  J'ai travaillé dans une très grosse boîte où cohabitent différents environnement très différents, je comprends qu'on puisse en arriver à un tel choix.
 
L'autre orientation est celle citée par Cyp: un environnement résolument orienté vers un type de business bien précis.  Par exemple un serveur web.
 
Les deux orientations sont défendables et ont chacune leurs avantages et leurs inconvénients.  Reste à voir lesquels on préfère et lesquels on veut pas voir.  C'est pour ça qu'il y a tant de SGBD(R) sur le marché.  A chacun son bonheur et aussi à chacun ses propres valeurs (MS c'est mal, Linux ça sux, et ceci j'aime pas, et cela j'aime bien).
 
Et les benchmarks ne sont qu'un facteur parmi tant d'autres (limites, stabilité, performance, prix, accessibilité, etc...).  Tous les facteurs ne sont pas forcément pertinents évidemment et il y a toujours ces abrutis qui diront: "moi j'achète ceci et rien d'autre".

ca c'est pas un scoop, je connais tres bien le gars responsable du dev des fonctions MySQL dans PHP, il m'a dit que 90% du code etait des includes parce que base toujours sur PHP 3.
Il va bientot sortir un module specialement optimise pour MySQL-4.
D'autre part avec MySQL-4.1 et son nouveau protocole gerant les prepared statement, le gain est assez significatif : il arrive a gagner plus de 20% en performance.

tiens je m'y mets aussi !!!!
je travaille essentiellement avec ASP, ADO , (et leurs équivalent .Net) et SQL server , et j ai eu l'occassion de jouer avec MySQL et PHP...
 
ben y a pas photos... J'ai monté un site en .net que je me suis amusé a refaire en php (ouais je voulais apprendre)!! Ben c'était kif kif (J'ai eu des pages qui s'affichaient plus vite sous PHP que sous .Net et réciproquement, ca dépendait des pages!!!)
 
(pis je trouve que .Net est un php adapté à l'asp...)