Fallstricke bei der Verwendung von MySQL als Datenbankwahl? [geschlossen]

Ich habe mehrfach online gelesen, dass MySQL eine schlechte Datenbank ist. Die Stellen, an denen ich dies gelesen habe, enthalten einige Themen zu Reddit, aber sie scheinen nie zu ergründen, warum es ein schlechtes Produkt ist.

Gibt es eine Wahrheit zu dieser Behauptung? Ich habe es nie über ein sehr einfaches CRUD-Szenario hinaus verwendet, und das war für ein Universitätsprojekt in meinem zweiten Jahr.

Welche Tücken, wenn überhaupt , gibt es , wenn MySQL als Datenbank entschieden haben ?

Es gibt zwei verschiedene Arten von Gefahren, die aus dem Einsatz von MySQL als Geschmack von RDBMS und diejenigen der Verwendung eines RDBMS anstelle von anderen Arten von Datenbanken.

Verwenden von MySQL anstelle von alternativen RDBMS:

• In dieser Wikipedia-Vergleichstabelle finden Sie verschiedene Vergleiche von MySQL mit anderen RDBMS.
• Sie werden Microsoft SQL Server sehr wahrscheinlich vorziehen, wenn Sie eine ASP.NET-Webanwendung erstellen, da das System so konzipiert ist, dass es gut zusammenarbeitet, was ich sowohl für Entwickler als auch für IT-Manager glaube
• Möglicherweise bevorzugen Sie Oracle, wenn Sie eine erweiterte DB-Einrichtung mit Clustering (Oracle RAC) oder erweiterten DB-Prozeduren benötigen. Nicht, dass MySQL viele der Funktionen nicht unterstützt, aber nach dem, was ich gesehen habe, ist die Wahrscheinlichkeit groß, dass Sie einen erfahrenen DBA finden, der dieses Zeug für Oracle kennt als MySQL.
• Siehe diese Frage bei SO für ausführliche Vergleiche von PostgreSQL mit MySQL , die es besser sagen als ich kann.
• Noch mehr SO: Nachteile von MySQL im Vergleich zu anderen Datenbanken

Verwenden von RDBMS anstelle anderer Typen:

• Informieren Sie sich über die Idee von "NoSQL" und anderen DB-Typen:
  • NoSQL: Wenn es nur so einfach wäre
  • (oben ist verlinkt von) Wann ist MongoDB oder ein anderes dokumentenorientiertes Datenbanksystem zu verwenden? ( mehr )
  • /software/5354/are-nosql-databases-going-to-take-the-place-of-relational-databases-is-sql-going
  • Wann wird CouchDB vs RDBMS verwendet?
• RDBMS nutzen die Indizierung stark für die Leistung. Bei sehr großen Datenbanken kann dies die Leistung beeinträchtigen oder sogar die optimale Anzahl von Zeilen pro DB / Shard verringern, für die mehr Hardware erforderlich ist
• Nicht so ideal, wenn Sie eine große Datenmenge speichern, aber weniger häufig lesen
• Wenn Sie nicht viele Auslandsbeziehungen haben, sind relationale Datenbanken möglicherweise nicht ideal (Dokumentenspeicher).

Abgesehen davon ist MySQL eine großartige Datenbank, und ich habe in den letzten 8 Jahren nicht in einem Unternehmen gearbeitet, das sie nicht in einer Vielzahl von Webanwendungen (wie E-Commerce, Websites / Apps) verwendet hat , Enterprise / B2B, Web-Spiele). Für die große Mehrheit der typischen Anwendungsfälle von Webanwendungen ist dies eine gute Wahl.

MySQL steht jetzt unter der Kontrolle von Oracle - obwohl Open Source, entscheiden sie immer noch über die Richtung des Projekts und was dabei herauskommt.

In Bezug auf eine schlechte Datenbank ist es einfach einfacher als einige andere.

Wenn Sie nach Schwachstellen suchen, werde ich Sie darauf hinweisen, nehmen wir zum Beispiel PostgreSQL.

1. In MySQL fehlen Containertypen und Arrays.
2. MySQL fehlen echte Sequenzen (sie verwenden die automatische Inkrementierung) - Mit Postgres-Sequenzen können mehrere Tabellen eine einzige Sequenz verwenden, sodass Sie die Kardinalität für mehrere Tabellen garantieren können.
3. Postgres ist ACID-konform, MySQL ist teilweise konform.
4. Postgres implementiert Zeichenvariationen und Text auf die gleiche Weise (Toast Tables) - dieser Ansatz ist besser als MySQL.
5. Postgres hat nur ein Speicher-Backend - das heißt, Sie haben garantiert überall die gleichen Funktionen.
6. Postgres erlaubt serverseitige Funktionen, die in TCL, Python, R und Perl geschrieben sind.
7. Postgres bietet eine gute Unterstützung für asynchrone Treiber in Python - ich denke, es ist mit MySQL ein Hit oder Miss

In der Vergangenheit war die Transaktionsunterstützung schwach, und Transaktionen sind wichtig, wenn Sie eine konsistente Datenbank führen müssen. Heutzutage ist der große Rap, dass Oracle es besitzt.

MySQL war lange Zeit eher eine "Spielzeug" -Datenbank. Es handhabte keine verschachtelten Unterauswahlen, unterstützte keine Datenpartitionierung, bot keine mehreren Transaktionsisolationsstufen an, unterstützte keine Trigger oder gespeicherten Prozeduren - viele Dinge. Viele Leute, die aus dem Oracle- oder SQL Server-Hintergrund stammen, haben dies abgelehnt.

Ich denke, der wahre Grund, warum Sie nicht viele Listen von MySQL-Mängeln sehen, ist, dass es eine ziemlich tollwütige Fangemeinde gibt, die jegliche öffentliche Erwähnung von MySQL löscht oder ablehnt. Ich weiß, wann immer ich Probleme erwähnt habe, sind die Antworten überwiegend negativ.

MySQL ist ACID-kompatibel, wenn es mit der InnoDB-Speicher-Engine verwendet wird - kein Grund, dies nicht zu tun. MySQL ist ACID-kompatibel (ab Version 5.5 ist InnoDB die Standard-Speicher-Engine).

MySQL bekommt viel schlechte Presse, weil es oft (oder bis zum Aufkommen von NoSQL) als das RDBMS der Wahl von Leuten verwendet wurde, die kaum eine Datenbank brauchten (und vielleicht nur begrenzte RDBMS-Kenntnisse hatten) und es daher in ziemlich klobigen Situationen verwendeten Weise.

Ich habe MySQL viel benutzt und seitdem 5.x hinzugekommen ist, gibt es sehr wenig zu bemängeln, was die 95% der Installationen anbelangt, bei denen die Anforderungen in der Mitte der Straße liegen.

Datenbeschädigung: http://planet.mysql.com/entry/?id=16232

Es ist aus dem Jahr 2008. Hoffen wir, dass sich die Dinge in der Zwischenzeit geändert haben.