Les pièges de l'utilisation de MySQL comme choix de base de données? [fermé]

J'ai lu en ligne à plusieurs reprises que MySQL est une mauvaise base de données. Les endroits que j'ai lus incluent des discussions sur Reddit, mais ils ne semblent jamais se pencher sur la raison pour laquelle c'est un mauvais produit.

Y a-t-il du vrai dans cette affirmation? Je ne l'ai jamais utilisé au-delà d'un scénario CRUD très simple, et c'était pour un projet universitaire durant ma deuxième année.

Quels pièges, le cas échéant , y a-t-il lors du choix de MySQL comme base de données?

Il existe deux types de pièges, ceux liés à l'utilisation de MySQL comme version de RDBMS et ceux liés à l'utilisation d'un RDBMS au lieu d'autres types de bases de données.

Utiliser MySQL au lieu des SGBDR alternatifs:

• Voir ce tableau de comparaison de wikipedia pour diverses comparaisons de MySQL avec d'autres SGBDR.
• Vous préférerez très probablement Microsoft SQL Server si vous créez une application Web ASP.NET, car le système est conçu pour bien fonctionner ensemble, je crois pour les développeurs et les responsables informatiques.
• Vous pouvez préférer Oracle si vous avez besoin d'une configuration de base de données plus avancée impliquant le clustering (Oracle RAC) ou des procédures de base de données avancées. Non pas que MySQL ne prenne pas en charge de nombreuses fonctionnalités, mais d'après ce que j'ai vu, vous êtes beaucoup plus susceptible de trouver un DBA expérimenté qui connaît ce genre de choses pour Oracle que MySQL.
• Voir cette question à SO pour des comparaisons approfondies de PostgreSQL à MySQL qui le disent mieux que moi.
• Encore plus SO: Inconvénients de mysql par rapport aux autres bases de données

Utiliser des SGBDR au lieu d'autres types:

• Lisez l'idée de «NoSQL» et d'autres types de bases de données:
  • NoSQL: si seulement c'était aussi simple que cela
  • (ci-dessus est lié à partir de) Quand utiliser MongoDB ou d'autres systèmes de base de données orientés documents? ( plus )
  • /software/5354/are-nosql-databases-going-to-take-the-place-of-relational-databases-is-sql-going
  • Quand utiliser CouchDB vs RDBMS
• Les SGBDR font un usage intensif de l'indexation pour les performances. Sur les très grandes bases de données, cela peut avoir un effet négatif sur les performances ou même réduire le nombre optimal de lignes par DB / Shard nécessitant plus de matériel
• Pas aussi idéal si vous stockez une grande quantité de données mais lisez moins fréquemment
• Si vous n'avez pas beaucoup de relations étrangères, les bases de données relationnelles peuvent ne pas être idéales (stockage de documents)

Cela étant dit, MySQL est une excellente base de données, et je n'ai pas travaillé dans une entreprise au cours des 8 dernières années qui ne l'a pas utilisée, dans une grande variété d'applications Web (telles que le commerce électronique, les sites Web / applications , entreprise / B2B, jeux web). Pour une grande majorité des cas d'utilisation d'applications Web typiques, c'est un excellent choix.

MySQL est maintenant sous le contrôle d'Oracle - bien qu'open source, ils décident toujours de la direction du projet et de ce qui y entre.

En termes d'être une mauvaise base de données, non, c'est juste «plus simple» que d'autres.

Si vous cherchez des faiblesses, je les signalerai pour vous, prenons l'exemple de PostgreSQL.

1. MySQL manque de types de conteneurs et de tableaux.
2. MySQL manque de vraies séquences (elles utilisent l'incrémentation automatique) - Les séquences Postgres permettent à plusieurs tables d'utiliser une seule séquence afin que vous puissiez garantir la cardinalité sur plusieurs tables.
3. Postgres est conforme à ACID, MySQL est partiellement conforme.
4. Postgres implémente la variation des caractères et le texte de la même manière (Toast Tables) - cette approche serait la plupart diraient meilleure que MySQL.
5. Postgres n'a qu'un seul backend de stockage - cela signifie que vous êtes assuré d'avoir les mêmes fonctionnalités partout.
6. Postgres autorise les fonctions côté serveur écrites en TCL, Python, R et Perl.
7. Postgres a un bon support pour les pilotes asynchrones en Python - je pense que c'est un peu hasardeux avec MySQL

Historiquement, la prise en charge des transactions était faible et les transactions sont importantes si vous devez conserver une base de données cohérente. De nos jours, le gros coup est qu'Oracle en est le propriétaire.

MySQL a longtemps été plus une base de données "jouets". Il ne gère pas les sous-sélections imbriquées, ne prend pas en charge le partitionnement des données, n'offre pas plusieurs niveaux d'isolement des transactions, ne prend pas en charge les déclencheurs ou les procédures stockées - beaucoup de choses. Beaucoup de gens venant d'Oracle ou de SQL Server l'ont rejeté.

Je pense que la vraie raison pour laquelle vous ne voyez pas beaucoup de listes des lacunes de MySQL est qu'il a une base de fans plutôt enragée qui les supprime ou les retire de toute mention publique. Je sais que chaque fois que j'ai mentionné des problèmes que j'ai rencontrés, les réponses ont tendance à être extrêmement négatives.

MySQL est compatible ACID lorsqu'il est utilisé avec le moteur de stockage InnoDB - aucune raison de ne pas le faire. MySQL est donc conforme ACID (à partir des versions 5.5, InnoDB est le moteur de stockage par défaut).

MySQL obtient beaucoup de mauvaise presse car il est souvent utilisé (ou était jusqu'à l'avènement de NoSQL) comme le SGBDR de choix par des personnes qui avaient à peine besoin d'une base de données (et peut-être avaient des compétences limitées en SGBDR) et l'ont donc utilisé dans un environnement plutôt maladroit manière.

J'ai beaucoup utilisé MySQL et depuis l'arrivée de 5.x, il y a très peu de raisons de s'en plaindre pour 95% des installations qui ont des exigences moyennes.

Corruption des données: http://planet.mysql.com/entry/?id=16232

C'est à partir de 2008. Espérons que les choses ont changé entre-temps.