Post by Pascal PoncetPost by Bruno BaguetteEn même temps, les développeurs qui ont besoins de procédures stockées,
triggers et fonctions utilisent plutôt des bases de données sérieuses
comme PostgreSQL.
Bon, on est un peu (voire totalement) hors charte mais, comme le
newsgroup est modéré, je suppose qu'on est implicitement autorisé à
développer le sujet.
On est complètement hors charte, je vais donc positionner la suite du
débat sur fr.comp.applications.sgbd, ca ne fera pas de tort (on y sera
en charte), et puis ca y roupille, pour le moment...
Post by Pascal PoncetEuh... MySQL, c'est pas un SGBDR sérieux ?
Faudra le dire à Google, Amazon, Fnac, etc.
Je veux bien en discuter, car rien n'est définitivement acquis, mais il
faudra quand même amener quelques arguments solides avant toute
conclusion hâtive.
Même dans le contexte particulier des routines, triggers et events, je
ne vois pas de faiblesse manifeste à leur implémentation de SQL 2003.
Je n'ai pas encore eu l'occasion de tester le parallélisme, la
réplication ou le clustering, mais je n'ai pas entendu dire que c'était
une daubasse.
Bon, puisque j'ai ouvert la fosse à trolls, j'assume ! :-)
Je précise que j'ai été zieuter les récents changements de MySQL par
honnêteté, dès fois que... Et j'ai bien fait puisque changements il y a eu.
A l'époque (un bail) où j'ai fait mes choix, MySQL ne gérait pas les
sous-requêtes, ni les procédures stockées. PostgreSQL répondait à mes
besoins, je n'ai pas changé de SGBDR depuis.
Jusqu'il y a peu (fin 2010), MySQL était une daubasse dans sa
configuration par défaut, c'est à dire avec le moteur MyISAM (pas de
clef étrangères, acceptation de données plus grandes que la colonne
censée la recevoir, ...)
En d'autres termes, vous pouviez virer un enregistrement référencé par
d'autres (et donc perdre la cohérence de vos données), ou vous pouviez
insérer une chaine de 200 caractères dans un varchar(20) sans que MySQL
ne vous refuse l'insertion (et donc vous retrouver avec une chaine
tronquée).
Enfin, si vous utilisez une table (en insert ou en update) en MyISAM
lors d'un plantage du serveur, vous aviez de bonnes chances de vous
retrouver avec une table corrompue.
Bref, utiliser MySQL avec MyISAM relève de l'inconscience (surement une
grosse partie des utilisateurs), ou de la folie furieuse à moins de
savoir *ce que l'on fait*.
Le rachat de MySQL par Oracle aura permit (c'est peut-être la seule
bonne chose), que le moteur par défaut ne soit plus MyISAM, mais bien
InnoDB (qui appartenait déjà à Oracle avant, si je ne me trompe pas).
Un comparatif des fonctionnalités et des performances serait intéressant
à refaire (à moins qu'un comparatif *récent* ne soit déjà fait). Je ne
suis pas bien placé pour le faire puisque je n'utilise que rarement
MySQL (et aussi parce que je n'ai pas le temps de le faire, mais ca je
ne le dis pas !).
Pour l'aspect de la réplication, je ne vais pas m'aventurer sur ce
terrain, je n'ai jamais utilisé cela avec MySQL (uniquement en
PostgreSQL). Donc je n'ai pas d'expérience à donner sur ce point ! :-)
Post by Pascal PoncetPost by Bruno BaguetteJe peux avoir loupé un épisode, mais l'avenir de MySQL n'est-il pas
incertain avec son rachat par Oracle ?
Hélas, il semble bien incertain, du moins dans ses perspectives de
développement, car Oracle est réputé le positionner définitivement en
entrée de gamme, anti-cannibalisation oblige.
Enfin, entre une DB MySQL/PostgreSQL,... ou une DB Oracle, il y a une
grosse marge de coût quand même (serveur, DBA,...).
Post by Pascal PoncetMaintenant, l'alternative semble très sérieuse du côté de MariaDB.
Voir [http://mariadb.org/].
De plus, pour revenir dans la charte, il n'y a apparemment aucun
problème à utiliser PHP en client.
Voir [http://kb.askmonty.org/v/mariadb-versus-mysql]
J'en avais entendu parler, mais j'ignorait qu'ils étaient compatibles
avec le client MySQL (quand on voit l'auteur, on comprend mieux ensuite).
Le tout est de voir s'il sera adopté largement, mais c'est sans doute
trop tôt ? Il y a aussi Drizzle, un fork signalé par Mickael.
--
Bruno Baguette