Discussion :

[gannher]

Mais dans la haute disponibilité et intégrité, la base de données seule ne fait pas tout. Il s'agit surtout de réplication de base sur plusieurs serveurs, de redondances, etc.

Je pense qu'on peut faire de la haute performance, haute disponibilité avec n'importe quelle BDD connues du moment que l'architecture des serveurs tient la route.

[Tesing]

Est ce qu'on peut reellement parler d'applications critiques. Grosse application, grosse base oui. En terme de criticité, je place les bases de l'EFS (Etablissement Fra,çais du Sang) bien plus haut qu'une bases de SMS

Parce qu'en terme de haute disponibilité, performance, cohérence et intégrité, effectivement Oracle, ou SQL Server et MySQL ne jouent vraiment pas dans la même cour.

Des vies ne sont certes pas en jeux mais c'est autre chose. C'est un très gros business.

Et en terme de performance et de disponibilité, dans un système de SMS, les contraintes sont assez fortes, non ?

[Tofalu]

Je pense qu'on peut faire de la haute performance, haute disponibilité avec n'importe quelle BDD connues du moment que l'architecture des serveurs tient la route.

Ben ça dépend comment se situe le compromis haute dispo / performance.

Sauf erreur de ma part, de ce que j'en sais, sous MySQL, la haute dispo réside surtout sur une complète réplication de la base sur les différents noeuds en service, ce qui implique évidemment une résistance amoindrie à la montée en charge (sauf si on est sur une structure orientée lecture) et un problème face à une volumétrie importante obligeant à faire évoluer l'espace de stockage sur tous les noeuds.

Donc ça marche super bien en cas de crash, mais comme les perfs ne sont pas toujours au rendez-vous, c'est parfois, à tord, abandonné.

Après peut être que ça a évolué depuis donc si tu as un lien n'hésite pas

EDIT : enfin, j'ajouterais que quand on critique MySQL, c'est surtout MyIsam qui est visé. MyIsam est à la fois un atout et un handicap pour mysql. Atout de démocratisation, handicap d'"amateurisme".

[Tesing]

Concernant le produit lui même, c'est peut etre effectivement son coté bidouille qui séduit : la possibilité de créer un "tableau" de données sans se soucier des vraies notions de conception de base de données.

Si tu fais références à la normalisation ca prends son sens dans un contexte transactionnel. Pour des systèmes ou les opérations de lecture sont majoritaires c'est différent. Les jointures deviennent trop nombreuses et même avec une utilisation intelligente des index ca ralentit les requêtes.

MySQL propose aussi un moteur transactionnel robuste : InnoDB qui permet d'assurer une certaine cohérence des données.

Maintenant, en terme de fonctionnalités, c'est sur que ca vaut pas Oracle ou SQLServer, mais il faut quand même reconnaitre les qualités de MySQL et pas cracher dessus à tort et à travers.

Pas de vues matérialisées, pas d'héritage, pas de possibilité de définir ses types, etc... Mais est ce que ces fonctionnalités sont vraiment nécessaires pour toutes les applications ?

J'ai pas assez d'expérience pour le dire.

Mais dans le développement web pour lequel MySQL est souvent employé je vois rarement les développeurs utiliser ses fonctionnalités. Et effectivement ce SGBD est utilisé souvent comme un tableau. Pour autant, c'est loin d'en être un.

[Erwy]

@ Lyche: Pour rajouter une autre référence, Facebook utilise que Mysql. Je pense donc que l'argument de la quantité de donnée est clairement parce que tu ne sais pas configurer MySql.

Sauf que comme déjà dit dans un débat SGBD, facebook utilise plusieurs centaines de moteur mysql, de plus ces données sont particulièrement bien segmenté et je les soupçonne d'avoir des moteurs dédiés pour les requ^tes plus transversales.
Donc l'argument de la quantité de donnée est tout à fait recevable.
Facebook, comme d'autre applis, nécessite une architecture de donnée qui nécessite plus des serveurs optimisés que des BDD performantes.
Sur un mode transactionnel, mysql peut tenir la route avec un volume de donnée correcte, parce qu'on est un peu dans un mode "j'écris un objet/je récupère un objet", dès qu'on passe à des requêtes plus "transverses" et à un fort volume de donnée on passe sur d'autre BDD : Oracle,DB2,SQL Server,Teradata etc.....

[Tofalu]

Si tu fais références à la normalisation ca prends son sens dans un contexte transactionnel. Pour des systèmes ou les opérations de lecture sont majoritaires c'est différent. Les jointures deviennent trop nombreuses et même avec une utilisation intelligente des index ca ralentit les requêtes.

Des bases full-lecture il n'y en a pas des masses sur le web, et j'ai pas vraiment d'exemple parlant avec MySQL. D'autre part, l'absence de relation montre un problème d'analyse, ce qui dans bien des cas traduit pleins d'autres problèmes et essentiellement de stockage. Dés lors que l'utilisateur a droit à la moindre écriture il me parait essentiel de poser l'intégrité référentielle ne serait ce que pour l'évolutivité de la base.

MySQL propose aussi un moteur transactionnel robuste : InnoDB qui permet d'assurer une certaine cohérence des données.

Là, tu es pas sympa avec InnoDb. C'est comme si ton employeur te disais : tous les mois je vais te verser un certain salaire ... dans l'idéal ça serait quand même bien qu'il te verse la somme dûe dans sa totalité non ?

SGBD est utilisé souvent comme un tableau. Pour autant, c'est loin d'en être un.

Un sgbd ou un tableau ?

[Lyche]

Exactement et je ne dis pas le contraire.
Je suis juste contre le fait qu'on dise que MySql ne puisse pas gérer de grandes quantités de données. C'est totalement faux, c'est bien souvent une histoire de clusterisation et de configuration.

Je ne descends absolument pas les autres BDD tels que SQL Server, Oracle ou autres. Je défends juste celle que j'affectionne et pour laquelle j'adhère à la philosophie.

tu insinues donc que MySQL peut-gérer les même types de bases que SQL Server ou Oracle.. Je te souhaites bon courage pour que ton navigateur web qui te fait tes extraction de bdd le supporte.. Oui MySQL est accessible via Web, côté perf peut mieux faire et côté sécurité n'en parlons pas -_-.

Certes, MySQL s'est amélioré, je ne dis pas le contraire, mais par pitié, cessez de dire que c'est efficace, regardez le forum, on est en bdd MySQL et on a régulièrement des plantages.. Et je ne pense pas que les responsables du forum soient des incompétents..
C'est très bon en lecture des données, mais dès qu'il s'agit de faire des traitement lourds, on touche le fond. Mais je ne m'attarderais pas sur le sujet, on va rentrer dans une guerre sans fin.

[Tofalu]

D'un autre coté, un forum n'est pas vraiment ce qu'il se fait de mieux en terme d'optimisation d'accès aux données. Beaucoup d'accès sont imbriqués et réitérés (ceci est dû à l'assemblage des différentes fonctionnalités). Un forum c'est une multitude de requêtes simples, c'est pas dit qu'on aurait un comportement très différent avec un serveur de BD Oracle. Il faudrait vraiment voir ce qu'il se passe au niveau du moteur de base de données isolé du serveur Web.

[mizuka]

MySQL n'est pas assez "fermé" pour qu'il puisse interesser Oracle, il s'agit d'un SGBD libre et Open-source, chose qui ne colle pas avec la mentalité Oracle, qui est celle de se faire encore plus de pognon et rien d'autre... déjà que l'avenir de Sun et de Java sont menacés avec ce rachat.

Le mieux serait qu'une communauté Open-source reprenne le projet MySQL en main et continue à le faire vivre tout comme Sun l'à fait depuis tout ce temps.

[GanYoshi]

Le mieux serait qu'une communauté Open-source reprenne le projet MySQL en main et continue à le faire vivre tout comme Sun l'à fait depuis tout ce temps.

J'imagine mal une "communauté" open-source reprendre le projet MySQL et continuer à le faire vivre comme l'a fait Sun.
Je crois qu'un tel projet nécessite une équipe de développeurs compétents et à plein temps, donc il faut que MySQL soit repris par une boîte qui s'en occupe.

[Lyche]

J'imagine mal une "communauté" open-source reprendre le projet MySQL et continuer à le faire vivre comme l'a fait Sun.
Je crois qu'un tel projet nécessite une équipe de développeurs compétents et à plein temps, donc il faut que MySQL soit repris par une boîte qui s'en occupe.

+1000

[Traroth2]

Le problème de la commission européenne est qu'elle ne prend ses décisions que dans une seule mesure : la concurrence (on pourrait dire le libéralisme économique). Toutes les décisions qui y sont prises ne le sont que pour eviter la mainmise d'une entreprise dans un secteur particulier.

C'est certes louable, mais cela la pousse à prendre des décisions dans des domaines ou elle n'est pas compétente. Le meilleur exemple en est l'informatique.

Quel est exactement le problème avec Oracle et mysql? Avec Mysql Oracle va toucher un marché qu'il ne connaissait pas : les petites applis et les sites web de petites et moyennes tailles. Avec qui sera-t-il en concurrence? Personne, ou presque (les autres tentatives sont à mon sens des echecs)... Mais c'etait déjà le cas de Mysql, puis de Sun avec le rachat de Mysql.

Pour les autres bases de données, Oracle restera en concurrence avec les acteurs majeurs de la BDD, comme IBM ou Microsoft. En cela le rachat de Mysql ne changera absolument rien.

Pour ce qui concerne Oracle, ce qui l'interesse est peut-être le fait que bien que ce soit un produit opensource, il n'est pas pour autant complètement gratuit. Et toutes les entreprises qui l'utilisent à destination du public doivent payer une licence. Pourquoi donc s'arrêter en si bon chemin? D'autant plus qu'un porduit opensource coute largement moins cher qu'un produit dont il faut protéger les sources et payer intégralement le salaire de tous les acteurs du développement du projet.

Ca veut dire qu'Oracle sera en position dominante sur tout le marché des SGBD, et ça c'est un problème. De plus, il faut arrêter de dire que MySQL, ce n'est que pour les "petites applis". Il ne faut vraiment pas bien le connaitre pour dire ça en 2009 !

[Traroth2]

C'est clair que Mysql est bien pourave

Merci pour cet apport inestimable au débat...

[The F0x]

Ca veut dire qu'Oracle sera en position dominante sur tout le marché des SGBD, et ça c'est un problème. De plus, il faut arrêter de dire que MySQL, ce n'est que pour les "petites applis". Il ne faut vraiment pas bien le connaitre pour dire ça en 2009 !

Maintenant on a plus le droit de couvrir tous les segments d'un marché sans se faire accuser de position dominante ? Je suis désolé mais c'est très mal connaitre la concurrence sur le marché des SGBD.

Quand au côté "petites applis" de MySQL, cela reste vrai même aujourd'hui, la différence entre "grosses" et "petites" application ne se fait sur la quantité de données gérées, mais sur la complexité des modèles de données a gérées, des garanties de perfromances, ainsi que de l'offre des outils intégrés afin d'assurer/assister/garantir l'interopérabilité avec les autres systèmes de production (les SGBD ne sont pas le centre du monde informatique).

[Tesing]

Là, tu es pas sympa avec InnoDb. C'est comme si ton employeur te disais : tous les mois je vais te verser un certain salaire ... dans l'idéal ça serait quand même bien qu'il te verse la somme dûe dans sa totalité non ?

Bah le gros problème c'est que InnoDB a été racheté par Oracle.

Au niveau cohérence il ne supporte pas autant que PostgreSQL. Pas possible par exemple de définir des contraintes sur les valeurs en entrée.

Et les futurs moteurs transactionnels (Falcon notamment) de MySQL devraient arriver avec la version 6.

Personnellement je pense que ca serait bien pour l'évolution de MySQL qu'il y ait une séparation avec Oracle car je vois mal Oracle encourager le développement d'une solution gratuite qui pourrait dans un futur certes lointain devenir équivalente à son produit phare.

[Tesing]

Maintenant on a plus le droit de couvrir tous les segments d'un marché sans se faire accuser de position dominante ? Je suis désolé mais c'est très mal connaitre la concurrence sur le marché des SGBD.

Quand au côté "petites applis" de MySQL, cela reste vrai même aujourd'hui, la différence entre "grosses" et "petites" application ne se fait sur la quantité de données gérées, mais sur la complexité des modèles de données a gérées, des garanties de perfromances, ainsi que de l'offre des outils intégrés afin d'assurer/assister/garantir l'interopérabilité avec les autres systèmes de production (les SGBD ne sont pas le centre du monde informatique).

Complexité du modèle à gérer je veux bien mais garantie de performances je ne suis pas d'accord. Ensuite pour l'interopérabilité il y a quand même de quoi faire.

[berceker united]

Bah le gros problème c'est que InnoDB a été racheté par Oracle.

Au niveau cohérence il ne supporte pas autant que PostgreSQL. Pas possible par exemple de définir des contraintes sur les valeurs en entrée.

Et les futurs moteurs transactionnels (Falcon notamment) de MySQL devraient arriver avec la version 6.

Personnellement je pense que ca serait bien pour l'évolution de MySQL qu'il y ait une séparation avec Oracle car je vois mal Oracle encourager le développement d'une solution gratuite qui pourrait dans un futur certes lointain devenir équivalente à son produit phare.

Je pense pas que Mysql puisse empiéter sur les plat de bande d'Oracle, cela s'adresse pas au même clients, ce n'est pas les mêmes besoins. Mais il est pas bon pour le marché qu'Oracle puisse avoir un monopole parce du coup, ils peuvent faire la pluie et le beau temps.

[voran]

Ce qui séduit et à fait le succès de MySQL ... c'est le cout !
A part ça ? je vois pas.

Les créateurs de MySQL sont gentils mais pas crédibles et limite ridicules.
Après avoir abandonné le produit on ne le demande pas leur avis.

MySQL pour les gros projets c'est sans doute possible mais il faut l'amour du risque ou s'appeler Google, Yahoo... avec les devs MySQL derrière.

Si ORACLE est contraint de jeter MySQL, PostgreSQL pourrait supplanter MySQL (enfin ?) . Et ce ne serait une excellente chose (de mon point vue )

[berceker united]

Ce qui séduit et à fait le succès de MySQL ... c'est le cout !
A part ça ? je vois pas.

Les créateurs de MySQL sont gentils mais pas crédibles et limite ridicules.
Après avoir abandonné le produit on ne le demande pas leur avis.

MySQL pour les gros projets c'est sans doute possible mais il faut l'amour du risque ou s'appeler Google, Yahoo... avec les devs MySQL derrière.

Si ORACLE est contraint de jeter MySQL, PostgreSQL pourrait supplanter MySQL (enfin ?) . Et ce ne serait une excellente chose (de mon point vue )

Lz plupart des utilisateurs de Mysql n'utilise qu'un faible pourcentage de ses capacités. Alors pourquoi penser que ça ira mieux avec PostgreSQL et pourquoi le proposer ?

[Gecko]

Postgre, pour ma part, s'oriente vers des utilisateurs plus avancé que mysql. Mysql est tip top pour les petits sites qui ne brassent pas des millions de visiteurs / jour. Quand il y a beaucoup de transfert Postgre reste mieux, il permet de mieux gérer les données et est plus rapide.

Dire que les gens passeront sous postgre perso j'y crois pas trop, sur une petite bdd postgre est plus long a réagir que mysql... En plus les gens préfèrerons ne rien toucher et ne mettrons plus rien à jour, ils se contenterons d'avoir un SGBD qui est périmé et plus supporté.

Mon avis sur oracle est que Mysql ne doit pas rester entre leur doigts, rien ne les empêches de continuer le dev et de le stopper du jour au lendemain. A partir du moment ou mysql est leur propriété ils en font ce qu'ils veulent et ça c'est pas bon... La loi du capitalisme est bien d'obtenir plus de benef que les autres non? Pourquoi oracle n'évinserai pas mysql à long thermes ? C'est utopique de penser qu'une société vas entretenir un SGBD qui l'a conccurencé longtemps gratuitement...

Dans tous les cas, si oracle garde mysql je change de SGBD pour être tranquil sur le long thermes