Open Source et pérénité des solutions.
Citation:
Envoyé par
epsilon68
moi je suis en face de clients que MySQL ou meme SQLite pourrait suffire, mais ils ont Oracle comme standard.
Le problème c'est aussi qu'ils doivent payer en interne pour une db, alors souvent le cout du projet est trop important...
(un standard ou rien du tout)
La différence fondamentale entre les gros SGBD et les SGDB libres que tout le monde connait ne réside pas tant dans les performances sur une application donnée que sur la pérennité du système à long terme. Lorsqu'une boite investit dans un SGBD, elle s'attend à pouvoir faire ses développement sur ce système pendant des années, voire des dizaines d'années. Elle veut que le vendeur lui livre des versions qui sont compatibles avec les programmes qu'elle a fait il y a 10 ans.
Hors, l'Open Source, c'est un peu la foire d'empoigne sur ce sujet. Seuls sont considérés comme intéressantes et digne de support les nouveautés. Dès lors qu'une technologie meilleure fait son apparition, il est demandé aux utilisateurs de l'utiliser et de convertir ses données et programmes pour se faire, et la technologie remplacée est trop souvent supprimée au bout d'un moment. C'est acceptable dans une entreprise relativement agile, mais une boite qui doit gérer 200 sites de par le monde et 30,000 employés aura bien évidemment plus de problèmes.
Un exemple, qui vient de m'arriver. Je viens de terminer un développement Linux pour un client, utilisant les technologies déployées sur les distributions Linux courantes (je veux dire, celles d'octobre/novembre de cette année) . Le client est content, on signe la recette, il paye. C'était il y a quelques semaines. J'ai du l'appeler en urgence la semaine dernière parce que soft livré ne fonctionnera probablement plus sur les prochaines versions des distributions Linux cible (c'est à dire dans 6 mois), de fait de l'abandon par la communauté d'une technologie que j'utilise au profit d'une autre. Je n'ai même pas le recul suffisant pour savoir si cette nouvelle techno répondra à mes besoins. Je sais juste que la techno que j'utilise moi a été déclarée obsolète, donc que le support va graduellement cesser, et que le client va devoir repayer pour des développement supplémentaires dans un produit terminé et livré.
Sur un composant aussi critique d'un SGBD, une entreprise ne peut pas se permettre ce genre de surprises. Avec des développements en interne qui peuvent couter des millions d'euros, se demander sans arrêt si une modification du code sera nécessaire d'ici à deux ans est un cauchemar (note: pour ceux qui pensent que MySQL est une institution pérenne, sachez que chaque nouvelle version introduit des changements incompatibles avec la version précédente. Cf chapitre 2.12.1.1 de chaque manuel MySQL.)
Donc, effectivement, prendre un des gros SGBD revient cher à court terme, surtout lorsqu'on produit un projet s'appuyant sur celui-ci. Mais les coûts sont maîtrisés. D'un autre coté, les risques inhérents à un SGBD Open Source peuvent faire grimper drastiquement le cout d'un projet à long terme dans des proportions totalement inconnues.
Après, à chacun ses priorités...