me retrouver : |
smartview |
twitter |
speakerdeck |
linkedin |
3 derniers articles : |
Quand j’en vois, je sais que ç’en est |
Mix-it & Sudweb |
Lecture : l’empire des coachs de Gori & Le Coz, 2006 |
recherche | archives | catégories | à propos

MySQL
Où en est MySQL ? en plein paradoxe a priori. D’abord les choses qui fâchent : La société est rachetée voilà à peu près 1 an et demi par SUN. Manifestement elle reste KO debout. On ne connait ni la roadmap qu’envisage Sun, ni si ils vont garder le modèle économique de la base de données opensource la plus répandue au monde. En décidant un silence radio de 6 mois suivant le rachat Sun n’arrange rien. Et ça bouge, en interne, certaines grosses pointures quittent le navire. Pas mal de choses assez excitantes semblent oubliées ou dans une impasse : par exemple Google devait intervenir sur une partie du code de MySQL (des plugins de recherches et d’analyses syntaxiques probablement), disparu, oublié. Heureusement rassurent certains, Sun est une boite qui va comprendre MySQL, et ce n’est pas l’un des gros comme Oracle ou Microsoft ou IBM. A ce sujet -bien embarrassé d’avoir laissé filer InnoDB chez l’ennemi (racheté par Oracle il ya quelques années)- MySQL s’est lancé dans la réalisation d’un moteur transactionnel maison : Falcon. Démarrage poussif de ce dernier qui reste encore en Alpha et dont les progrès paraissent trop lents pour rassurer. On se demande même si il n’est pas gelé. Compétition en interne, on sent bien que les ingénieurs de Sun ont décidés de se la jouer “pro” contre les savants fous créatifs de la communauté (si je caricature). Ca remue je vous dis. Monty Widenius se lance dans Maria (un moteur de stockage myisam évolué), en sent bien qu’il est exclu, il ne tarde pas à quitter MySQL, et fonde récemment avec les excellentissimes Percona l’Open Database Alliance. Et patatras, voilà 6 mois, Oracle rachète Sun… Et c’est reparti pour un tour : pas de visibilité, pas de plan, l’inconnu.

Drizzle
Et pourtant beaucoup de bonnes choses : malgré un silence insistant de 6 mois les ingénieurs de chez Sun sortent soudain une version 5.4 de MySQL qui, si l’on en croit les benchmarks, pulvérisent les performances de ses prédécesseurs. On commence aussi à comprendre la position de Sun concernant le marché : ils offrent des solutions packagés/optimisés hardware/serveur de données. Et puis Oracle, ni Sun, n’osent bouger : le moteur Maria est déjà devenu un projet opensource à part, Percona offre des releases de MySQL patchées et propose aujourd’hui son propre moteur stockage et son propre outil de backup basés sur InnoDB. Drizzle (là aussi des anciens de MySQL) apparaît (comme très prometteur). Bref au moindre mouvement la communauté risque de faire un fork, si ce n’est déjà le cas.
Enfin autour de ma petite fenêtre je vois bien que les projets opensource n’ont jamais eu autant de succès, je vois bien que MySQL pénètre chez des clients qui ne juraient jusqu’à présent que par Oracle ou DB2.
This entry was written by , posted on September 11, 2009 at 5:38 am, filed under database, opensource and tagged db2, drizzle, google, innodb, monty widenius, mysql, open database alliance, opensource, oracle, sun. Leave a comment or view the discussion at the permalink.
Lors des appels d’offres auxquels je suis confronté, on oppose souvent eZPublish & Typo3. Je propose le plus souvent eZPublish. Pourquoi choisir eZPublish plutôt que Typo3 ? Concernant cette question chacun peut défendre sa chapelle avec des arguments techniques et fonctionnels solides.Pour de multiples raisons je préfère aujourd’hui et de loin eZPublish (cela pourrait changer, mon avis n’était pas aussi tranché il y a un ou deux ans). Je ne vais pas maintenant détailler pourquoi, mais je peux rapidement mettre en évidence deux défauts qui me paraissent rédhibitoires de Typo3 sur le plan de la productivité.
Typo3 possède un langage de script propriétaire (le typoscript), qu’il soit bon ou mauvais peu importe, mais il est très long à prendre en main. Si donc une nouvelle équipe est amenée à intervenir sur un projet Typo3, la charge liée à sa montée en compétence est plus lourde que celle du PHP standard de eZPublish. Trouver un développeur est aussi moins simple que de trouver un développeur PHP. Problème de productivité donc. Le deuxième point est aussi lié à typoscript, on doit le modifier dans l’interface web du backoffice. Ceci interdit l’utilisation d’un gestionnaire de source classique type Git ou Subversion. C’est donc très dommageable, le script ne peut être modifié que par une seule personne à la fois. Problème de productivité encore.
Ces deux défauts ne sont pas anodins. Ils handicapent fortement le TCO (le fameux coût de revient global) d’une solution comme Typo3. eZPublish quand à lui n’utilise que des standards : PHP. De fait il est bien plus ouvert même si Typo3 est la solution 100% communautaire.
This entry was written by , posted on September 4, 2009 at 11:32 am, filed under opensource, php and tagged ezpublish, typo3. Leave a comment or view the discussion at the permalink.