[gull] Il faut reconnaitre que la Wikipedia est drole

Daniel Cordey dc at mjt.ch
Mon Sep 26 14:41:15 CEST 2005


On Monday 26 September 2005 13:59, Marc SCHAEFER wrote:

> MySQL est une base de données non générale, qui n'implémente pas tout ce
> à quoi on pourrait s'attendre après avoir compris les fondements des
> systèmes de gestion de bases de données. Même si ses dernières versions
> vont dans la bonne direction, ce n'est pas encore un système
> qui permet de véritables développement corrects SGBD. Et pire, il donne
> l'illusion à ses utilisateurs de les offrir.

Cela depend de la version dont on parle. Dans tous les cas MySQL a fait le 
choix de ne pas integrer  de moteur transactionnel dans le but d'atteindre 
les meilleures performances. Celui qui utilise MySQL comme un base 
transactionnelle joue a la roulette russe... avec la garantie que la balle 
finira par partir :-) De plus, et jusqu'a la version 4.1 (pas encore regarde 
la 5.0), l'emploir de "FOREIGN KEYS" implique des fichiers d'indexes en 
InoDB, au lieu des standard MyISAM. Ceci a pour effet de doubler la taille 
des fichiers de cles...

Bref MySQL a des limitations et elles sont clairement expliquees. Cette SGDB 
ne pretend pas offrir les memes fonctionalites que PostGress, Oracle, DB2, 
Sybase, etc. Mais, les meilleures performances dans une utilisation bien 
precise.

> Il y a certes des cas où une base de données non générale peut suffire,
> mais alors il y a d'autres choix que MySQL (p.ex. DBM, voire SQL-DBM).

Je ne connais pas SQL-DBM, mais le veritable probleme de DBM est l'adjonction 
d'enregistrements nouveaux qui ralentissent massivement les performances. A 
contrario, pour un "domaine" de donnees connues, les performances en 
interrogations sont les meilleures. Il importe donc de bien determiner 
l'usage de ses donnees et de decider en fontion des ces imperatifs. Inutile 
d'employer un canon a mouche !

> Justement, c'est souvent parce qu'on n'a que MySQL qu'on ne voit pas les
> fonctionnalités qui pourraient être utilisées déjà dans le design de
> l'application.

Je dirais : "que l'on ne connait pas ce qu'est une vraie DB relationnelle... 
incluant la fiabilite.". Il faut etre bien conscient des limitations de 
MySQL; et dans ce cas, le choix peut parfaitement s'averer logique.

> Il est évident que le portage d'une application limitée à MySQL sur
> PostgreSQL ne donnera pas forcément de meilleurs résultats.

C'est presque certain. Sauf, s'il s'agit d'une etape parceque l'on a besoin 
d'un moteur transactionnel. Auquel cas le retour vers MySQL ne sera plus 
possible.

> Le seul cas où une base de données hyper-simple peut être employée c'est
> lorsqu'une couche intermédiaire (moniteur transactionnel, etc) sort de
> la base de données les fonctionnalités SGBD correspondantes.

On utilise alors pleinement MySQL car il a ete concu dans cette optique 
uniquement. Il n'est pas necessaire de mettre du transactionnel la ou cela 
n'est pas necessaire.

> Dans mon expérience pratique jusqu'ici, MySQL m'est apparu comme ayant
> plus de problèmes de fiabilité que PostgreSQL. Mais il faut bien dire
> que depuis 2-3 ans je n'ai plus véritablement utilisé MySQL, il se peut
> que la situation se soit améliorée.

Pour repondre, il faudrait que l'on utilise les deux en // avec la meme 
application. Lors du choix que nous avons effectues pour nos applications, 
nous nous sommes pose la question Postgress/mySQL. Nous avions (et avons 
toujours) un besoin de performance absolue et une architecture transtionnelle 
ne nous servait a rien. Donc, je ne peux que donner une statisqtique 
concernant nos serveurs. Nous avons deux gros serveurs MySQL avec des bases 
pour chaque serveur : ~40GB data, 130 tables et 12 bases; certaines tables 
ont >20 millions de cles. Il y a deux ans, une coupure de courant a necessite 
l'execution d'un "REPAIR TABLE" sur certaines tables et tout est rentre dans 
l'ordre. Sans cela, notre serveur de production n'a pas ete redemarre depuis 
295 jours et a depuis traite plus de 2.4 milliards de transactions... 
(moyenne 101 transations par seconde 24/24 - 7/7) sans aucun probeleme 
quelqconque... zero. Bien sur, ce n'est pas une garantie, mais uns simple 
statistique concernant un usage determine. Ceci concerne la version 4.0 et 
nous nous appretons a passer a la 4.1. Je ne sais pas ce qui en est de 
Postgress, mais j'imagine que ca ne doit pas etre inferieur :-)


> [*] troll

Nous sommes deux participant de "troll" puisque nous ecrivons des choses qui 
n'ont rien a voir avec le sujet initial ("Re: [gull] Il faut reconnaitre que 
la Wikipedia est drole"). Quoique... cela peut aussi un moyen d'empecher un 
vrai "troll" a ce sujet :-)

dc



More information about the gull mailing list