Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Qu'Oracle la conserve
Qu'Oracle s'en débarasse
De passer par une fondation multi-vendeurs
Autre (précisez svp)
Discussion :
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.
Des vies ne sont certes pas en jeux mais c'est autre chose. C'est un très gros business.Envoyé par Tofalu
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.
Et en terme de performance et de disponibilité, dans un système de SMS, les contraintes sont assez fortes, non ?
Ben ça dépend comment se situe le compromis haute dispo / performance.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.
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".
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.
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.....
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.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.
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 ?MySQL propose aussi un moteur transactionnel robuste : InnoDB qui permet d'assurer une certaine cohérence des données.
Un sgbd ou un tableau ?SGBD est utilisé souvent comme un tableau. Pour autant, c'est loin d'en être un.
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.
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.
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.
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
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 !
Merci pour cet apport inestimable au débat...
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).
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.
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.
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.
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 ?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
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
Répondre avec citation
Partager