Reprise du message précédent :
bon, masklinn, tu retrouves le lien où des tests montrent que postgre est plus rapide que mysql dans bien des cas (plutôt que dire "oui mais toi tu parles en théorie" "ah mais nan gnagnagna" "miroir magique qui renvoie tout" ), et on en parle plus, mais arrêtez, sans déconner

Cosmoschtroumpf,
 
Je connais ce bench, mais le probleme c'est que les utlilisations des SGBD sont totalement différentes les unes des autres, ainsi que les conditions, et tu peu "fabriquer un bench" qui va donner raison à un SGBD dans un cas, mais que pour ton appli à toi c'est un autre SGBD qui sera performant.
 
Par exemple, SQL-Server sur une machine avec peu de RAM sera une limace comparée à MySQL, inversement sur une machine avec beaucoup de RAM, et en mode transactionel, SQL-Server sera plus rapide que MySQL.
 
On à fait des benchs en interne MySQL versus PostgreSQL, MySQL était loin de devant, en tout cas sans transactions. Ca n'empèche pas que PostgreSQL est un excellent SGBD, et que dans certains cas c'est un SGBD plus adapté que MySQL. (pour une gestion Pro avec transactions et des fonctions avancées par exemple).
 
Cosmoschtroumpf,
 
Si tu penses que tout est réglé par un bench tu est encore dans la naiveté la plus totale...
 
Je peu te faire un bench avec plusieurs SGBD dont par exemple SQL-Server versus FirebirdSQL, ou SQL-Server arrivera premier en OLTP, et FirebirdSQL bon dernier , et inversement Firebird SQL premier en OLCP, et SQL-Server bon dernier.
 
Ca dépends de ton besoin, de la situation, etc...
 
Sinon il y aurais pas 10 SGBD (principaux) mais un seul...
 
Encore une fois, tout est relatif.
 
ll n'y à pas "un meilleur SGBD", il y à plusieurs meilleurs SGBD, en fonction des besoins.
 

k, super, mais tout ça n'aide pas à répondre au sujet initial

... ceci ne serait il pas l'hopital qui se moque de la charité, quand on connait ton passif sur ce forum, cher Vazkor ?

Nan mais moi je suis d'accord avec Paul JR.
 
A la base, un tocard habitué de blabla passe ici, dépose un lien dans le topic le plus débile du monde, j'ai nommé "blabla", et on va l'ensemble des détruts du forum qui déboulent et racontent des conneries.
 
Malsklinn et Paul JR ont "raison" tous les deux, dans la mesure où ils ne parlent pas de la même chose, mais que le côté oeillères propre à 99% des habitués du forums (vous en faites pas, je me compte dans les 99%) partent dans un dialogue de sourd suite à une inexactitude dans un post.
 
L'un dit "ouin MySQL c'est pas mieux que le reste", l'autre répond "Y'a pas de meilleur SGBD, ça dépend de l'utilisation qu'on en fait".
 
T'ain faut quand même pas être accadémicien pour savoir que ces deux phrases veulent dire la même chose si ?
 
Oui, un fichier texte géré par un unique thread écrit COBOL 8bits en mode exclusif PEUT s'avérer la meilleur des solution poussibles pour un problème donné.
Et non, une ferme de 5000 serveurs TeraData peut ne pas arriver au quart de millième de la cheville de cette solution.
 
Et pour rappel, c'est bien plus souvent le cas... Sinon pourquoi près de 100% des applications utiliseraient des fichiers de configuration au lieu d'une base de données ?
 
Enfin, tout ça pour dire qu'après s'être éloigné du sujet initial, on s'éloigne cette fois-ci du HS.
 
L'auteur de ce topic (qui doit avoir caputilé depuis vu qu'il n'est jamais revenu) sera particulièrement reconnaissant envers le crétin qui a collé un lien dans le sujet blabla

T'es vachement fort pour savoir ce que pense l'auteur du topic hein
A la limite, vu que tu sais ce qu'il pense à sa place, tu peux continuer la discussion à sa place, on fera comme si.

pis t'es t'es super fort pour faire des posts inutiles qui ne servent qu'à mettre de l'huile sur le feu

 
http://tweakers.net/reviews/657/6 et http://tweakers.net/reviews/649/7 http://tweakers.net/reviews/649/8 http://tweakers.net/reviews/649/9 mais ils ne donnent pas le détail des configs, donc on ne sait pas si MySQL utilise des tables en MyISAM ou en InnoDB

 
Huile sur le feu ?
Hopital, charité tout ça. Tu m'as pourri la gueule alors que finalement devant Masklinn tu te fais tout gentil "ah mais oui normal ils ont raison tous les deux mais ils ne se comprennent pas". A la base, j'ai quand même juste dit que les transactions n'étaient pas par définition une caractéristique des SGBDR. Appelle ça de l'enculage de mouche si tu veux, mais bon, j'essaye d'apprendre des choses exactes si possible.
Ok, je donne souvent dans un style très déplaisant, m'enfin je rappelle à toute fin utile que la modération existe aussi sur prog, qu'il suffit juste de demander.

Ah, c'est toi le responsable ?
 
Loin de moi l'envie de chercher à modérer qui que ce soit. De toute façon, Harko suit déjà ce topic et devrait pas tarder par finir par le fermer puisqu'il ne sert plus à rien à l'auteur du topic, et surtout, que ce dernier ne semble pas vouloir revenir apporter des précisions quant à ce qu'il voulait exactement (il suffit de lire les premiers posts pour voir que c'est parti dans tous les sens, chacun selon son interprétation de la question).
 
Ensuite, personnellement, je suis un gars bourré de défaut, et je suis le premier à le reconnaître. Seulement, une de mes qualités je pense, c'est toujours de tenter d'apporter une pierre à l'édifice dans une conversation (et tant pis si c'est une connerie, dans le tas y'aura toujours un truc intéressant).
Par contre, je perds rapidement patience lorsque j'argumente dans le vide. Je me fais chier à expliquer pourquoi un SGBDR utilise obligatoirement, au moins de façon interne, des transactions, et on me répond qu'un SGBDR n'est pas forcément un SGBD transactionnel. Je vais pas relancer le débat, mais j'aimerais quand même que certains admettent que l'infirmation qui m'est faite n'a aucun rapport avec mon affirmation. Je ne parle même pas du coup où on m'explique qu'on peut très bien utiliser une BDR sans transaction... Bah oui, on peut même utiliser une BDR sans SGBD. Les meilleurs exemples, ce sont les fichiers XML, ou un simuli de SGBD, basé sur des fichiers plats, tel que DBase.
 
Pour ma culture personnelle, j'apprécie bien l'exemple d'eBay, mais à la base, ça n'avait rien à voir avec le schmilblik, et je ne pense pas que ce soit criminel que de finir par s'impatienter à force de s'égosiller dans le vide

Au temps des cavernes, on la posait sur la table.
Depuis que les bits sont numériques, tout est plus complexe.
 
Les comparaisons de perf de SGBD, ça sert à rien. A la fin c'est mySQL qui gagne, parce que les noobs ne savent pas taper postgraisseQL correctement sous google.
 
Et oui, c'est la vie.

 
Dans ce bench (ou on ne sait effectivement pas si MySQL est utilisé avec ou sans transaction), PostgreSQL fait une différence quand on augmente le nombre de connexions, hors généralement ce qui se passe c'est qu'on met en ligne une application qui gére un très grand nombre d'utilisateurs, mais l'application elle meme n'utilise que très peu de connexions, c'est un peu le principe du serveur d'applications, donc meme si l'application à par exemple 3000 utilisateurs connectés, la base de données n'à elle qu'à gérer que quelques connexions en réalité.
 
Donc dans la pratique, avec quelques connexions MySQL est très performants, et sans doute encore beaucoup plus sans les transactions. Donc si ce bench à bien été fait avec les transactions, MySQL est donc probabement la solution la plus rapide dans ce cas d'utilisation.
 
Je précise que ca n'est pas moi qui à fait dévié ce sujet, moi j'ai commencé par répondre à la question, qui ne porte pas sur le SGBD, mais le développement, et je n'ai dévié du sujet que pour répondre à une série de messages hors sujet genre "mysql sapu".
 
Et cela m'à choqué parce que dans certains cas d'utilisation (l'utilisation en mode non transactionnelle, mode réservé aux débiles mentaux    ) au contraire mySQL ca pu pas du tout...

Au dessus de 6
 
Lulz

Généralement environ 3 connexions suffisent, d'une part, et d'autre part si ce bench à bien été fait avec les transactions, MYSQL est beaucoup plus rapide que PostGreSQL en mode non transactionel, et plus rapide que pratiquement tous les autres SGBD d'ailleurs (désolé j'ai pas le bench sous la main, mais il y à un autre bench qui compare MySQL en mode non transactionel à tous les autres SGBD qui eux sont tous en mode transactionnel, et MySQL arrive en tête, mêmes devant des SGBD très couteux).

Dans ce bench ci : http://wskills.blogspot.com/2007/0 [...] hmark.html ,  
de janvier 2007, testé avec les transactions, MySQL (avec les transactions !) est deux fois plus rapide que PostGreSQL. Donc vous imaginez combien de fois plus rapide sans les transactions ?
 

 
Précisons que le test appliqué est le TPC-C, qui est un test qui essaye de simuler la charge d'un SGBD en utilisation réelle ("it combines read-only and update intensive transactions simulating the activities found in complex OLTP enterprise environments" ).