8 MySQL-Fallstricke, die Sie unbedingt kennen sollten

Mysql ist einfach zu installieren, schnell und funktionsreich. Darüber hinaus ist es auch ein Maßstab für die Open-Source-Bewegung. Seine großartigen Erfolge zeigen uns, dass ein erfolgreiches Unternehmen auf Open-Source-Code aufgebaut werden kann.

Allerdings hat jeder, der MySQL verwendet hat, mit der Faust auf den Monitor geschwenkt. Aber Sie können keine Technologie erfinden, die Tausende Zeilen Internetdaten pro Sekunde fehlerfrei speichern kann.

Zur Vorfreude auf diesen Sommer listen wir 8 Gründe auf, sich über relationale Open-Source-Datenbanken zu beschweren. Die unten aufgeführten Gründe beschränken sich nicht nur auf MySQL, einige beziehen sich auch speziell auf relationale Datenbanken. Wenn wir relationale Datenbanken und MySQL nicht verstehen, werden wir immer im Denken der 1990er Jahre stecken bleiben. Wir müssen diese abreißen und dann wieder aufbauen. Oder wir greifen auf eine kürzlich populäre Datenbank zurück, die es noch nicht lange genug gibt, um eine Reihe von Gründen wie den folgenden zu rechtfertigen.

Tief verwurzelte Fehler

Jedes große Paket hat Fehler. Wenn Sie jedoch etwas tiefer graben, werden Sie feststellen, dass Fehler im Zusammenhang mit MySQL ihr eigenes System haben. Plötzlich müssen Sie aufpassen, denn NULL wird nicht auf die gleiche Weise angezeigt, Fremdschlüsseleinschränkungen funktionieren nicht so, wie Sie denken, und selbst die automatische Inkrementierung des Primärschlüssels geht schief.

Es gibt viele kleine Probleme, die nicht immer behoben werden können. Deshalb führen manche Leute eine Liste. Glücklicherweise unterhält MySQL ein sehr gutes Fehlermeldesystem, sodass wir Dinge erfahren, die wir uns nicht vorstellen können, und wissen, dass andere die gleiche Tortur durchmachen.

Die Unflexibilität relationaler Tabellen

Relationale Tabellen sind organisiert, und die Organisation ist gut – sie zwingt Programmierer jedoch dazu, einige Daten in ein definiertes Schema in der Spalte zu kompilieren oder hineinzuzwängen. Einer der Gründe, warum NoSQL immer beliebter wird, ist, dass es Programmierern genügend Flexibilität bietet, um die Nutzung von Datenbanken zu beschleunigen. Wenn eine Straßenadresse eine zusätzliche Zeile benötigt, können Sie diese problemlos in ein NoSQL-Dokument einfügen. Wenn Sie einen komplett neuen Datenblock hinzufügen möchten, egal was dieser enthält, kann das Dokumentmodell Ihre Daten auch unverändert übernehmen, ohne sie in das benötigte Datenformat ändern zu müssen.

Stellen Sie sich vor, Sie erstellen eine Tabelle mit allen Postleitzahlen im Ganzzahlformat. Diese Tabelle ist sehr effizient und die von ihr durchgesetzten Regeln sind sehr gut. Plötzlich hat jemand eine neunstellige Postleitzahl mit Bindestrichen hochgeladen. Oder vielleicht erhalten Sie einen Brief von einem Kunden aus Kanada mit einer Postleitzahl darauf.

Zu dieser Zeit herrschte alles im Chaos. Der Chef verlangt, dass die Website innerhalb weniger Stunden wieder betriebsbereit ist. Es bleibt jedoch keine Zeit, die Datenbank neu aufzubauen. Was können Programmierer tun? Vielleicht können Hacker genutzt werden, um die kanadische Postleitzahl vom digitalen Base64-Format in das Base-10-Format zu ändern? Oder eine Hilfstabelle einrichten, die Escape-Codes verwendet, um die tatsächliche Postleitzahl usw. anzugeben? Wer weiß? Hacker gibt es überall und sie sind gefährlich. Aber Sie haben keine Zeit, es herauszufinden.

Die Assoziationsregeln von MySQL sorgen dafür, dass jeder ehrlich und vorsichtig ist, aber sie zwingen uns, das Problem zu vermeiden, anfällig für Angriffe und Täuschungen zu sein.

Gemeinsame Abfrage JOIN

Es war einmal eine große Innovation in der Geschichte der Informatik, Daten in separaten Tabellen zu speichern. Der getrennte Tisch hat nicht nur eine einfache Struktur, sondern vereinfacht auch die Verwendung. Für die Abfrage ist jedoch die Verwendung einer Join-Anweisung erforderlich.

SQL stürzt Entwickler durch komplexe Abfragen, die durch eine Reihe von Verknüpfungen erstellt werden, in den Abgrund der Verwirrung und Verzweiflung. Darüber hinaus muss die Speicher-Engine die Join-Anweisung effizient und optimal analysieren. Entwickler müssen sich den Kopf zerbrechen, um Abfrageanweisungen zu schreiben, und die Datenbank analysiert sie dann.

Aus diesem Grund verzichten viele Entwickler, die sich auf die Laufgeschwindigkeit konzentrieren, auf Datenuntertabellen und verwenden stattdessen nicht standardmäßige Datentabellen. Unterscheiden Sie nicht zwischen Datenentitäten und speichern Sie alle Daten in einer großen Tabelle, um komplexe Abfragen zu vermeiden. Das geht wirklich schnell und dem Server geht nicht der Speicher aus.

Speicherplatz ist heutzutage billig. 8-TB-Festplatten sind bereits im Angebot, größere sind bald erhältlich. Wir müssen uns nicht länger den Kopf zerbrechen, um Join zu nutzen.

Fork-Verwirrung

Ja, ein solider, gut unterstützter MySQL-Fork kann Konkurrenz und Auswahl bringen, aber auch Verwirrung und Verwirrung stiften. Erschwerend kommt hinzu, dass es einen MySQL-Zweig namens MariaDB gibt, der von Monty Widenius verwaltet wird. Er ist auch am Schreiben von MySQL beteiligt. Ist MariaDB also wirklich unabhängig und unserer Unterstützung würdig? Oder ist es MySQL? Sollten wir beim Kerncode bleiben, der von der Organisation betrieben wird, die die ursprüngliche MySQL-Datenbank erstellt hat? Oder sollten wir uns den oft coolen Überläufern anschließen, die als schlauer gelten?

Und wie erhalten wir Informationen zur Kompatibilität? Einerseits sind wir davon überzeugt, dass MariaDB und MySQL sehr ähnlich sind. Andererseits müssen wir glauben, dass es einen Unterschied gibt – warum streiten sich sonst alle darüber? Vielleicht funktionieren sie in beiden Lagern gleich, was die Leistung und den Umfang unserer Abfrage betrifft? Aber vielleicht sind sie anders – oder werden in Zukunft anders sein.

Storage Engine-Verwirrung

MySQL ist de facto nicht dieselbe Datenbank, sondern besteht aus mehreren Datenbanken, deren Details größtenteils durch eine einheitliche Oberfläche verdeckt sind. Am Anfang gab es eine MyISAM-Engine, die zwar schnell, aber hinsichtlich der Konsistenz nicht vollständig war. Manchmal ist es gut, wenn Sie Geschwindigkeit brauchen und inkonsistente Ergebnisse akzeptieren können.

Als die Leute mehr brauchten, erschien InnoDB mit vollständiger Transaktionsunterstützung. Aber das reicht nicht aus. Jetzt stehen möglicherweise 20 Speicher-Engines zur Auswahl – genug, um einen Datenbankadministrator in den Wahnsinn zu treiben. Natürlich gibt es Zeiten, in denen es schön ist, zwischen verschiedenen Speicher-Engines zu wechseln, ohne Ihr SQL neu schreiben zu müssen, aber nach dem Wechsel herrscht immer Chaos. Soll ich MyISAM oder innoDB als Engine für diese Tabelle wählen? Werden die Daten, die ich ausgeben möchte, alternativ im CSV-Format vorliegen?

Gewinnmotiv

Obwohl MySQL ein erfolgreiches Open-Source-Produkt ist, ist es immer noch ein Geschäft voller professioneller Entwickler, die damit bezahlt werden. Während die meisten Benutzer weiterhin die beste Erfahrung machen, die Open-Source-Lizenzen bieten, besteht kein Zweifel daran, dass dieses Unternehmen immer noch Schwierigkeiten hat, genug Geld zu verdienen, um den Betrieb aufrechtzuerhalten. Dies führt zu einer seltsamen Aufteilung des freien Codes zwischen „Community Editions“ und Vollprodukten, die an Unternehmen verkauft werden.

Sollten Sie bezahlen? Wie viel Geld verdienst du hier? Ist es fair, mit einer Community-Version zu arbeiten? Sind die zusätzlichen Funktionen in der Enterprise-Version nur eine Spielerei, um uns dazu zu verleiten, mehr zu bezahlen? Dies zeigt zumindest, dass es sich um eine weitere Reihe von Fragen handelt, die beantwortet werden müssen. Welche Version soll ich wählen? Unter welcher Lizenz? Welchen Funktionsumfang soll ich nutzen?

Fehlende native JSON-Unterstützung

Der beste Weg, das Alter von MySQL zu erkennen, besteht darin, es zu installieren und dann zu erkennen, dass Sie weitere Treiber hinzufügen müssen, um es nutzbar zu machen. MySQL kommuniziert normalerweise über Port 3306 und gibt typischerweise formatierte Daten aus, die es nur schwer verstehen kann. Wenn Sie möchten, dass Ihr Code mit ihm kommuniziert, müssen Sie eine weitere Codeebene hinzufügen, die die Sprache von MySQL in etwas Nützliches übersetzt. Der Code für diese Ebenen wird als Bibliothek verteilt, was häufig den Erwerb einer kommerziellen Lizenz erfordert.

Moderne Datenspeicherschichten kommunizieren oft direkt in JSON. Obwohl MySQL und MariaDB jetzt über die Möglichkeit verfügen, den JSON-Teil von SQL zu analysieren, ist dies bei weitem nicht gut genug, und die native JSON-Schnittstelle wird bereits häufig in CouchDB, MongoDB oder einem der neuesten Tools verwendet.

Der Aufstieg von Closed-Source- und proprietären Modulen

Habe ich schon erwähnt, dass MySQL Open Source ist? Es handelt sich, abgesehen von einigen neueren, nicht-Open-Source-Codes und proprietären Modulen, um den „Open-Source-Kern“. Programmierer müssen essen und Oracle muss die Früchte seiner harten Arbeit gegen Geld eintauschen. Dies ist eine der Realitäten des Geschäftslebens. Es ist nicht wie in Krankenhäusern, wo man mit MySQL kostenlose medizinische Versorgung erhält. Es ist nicht wie bei den Landwirten, die MySQL verwenden, um Lebensmittel zu verschenken.

Es ist ein bisschen unfair, von MySQL zu verlangen, dass es sich immer an einen sehr hohen Standard hält, denn Open-Source-Erfolg kann eine Falle sein. Das liegt nur daran, dass es von Anfang an kostenlos sein kann, aber das bedeutet nicht, dass es immer so sein kann. Wenn Unternehmen viele neue Funktionen wünschen, müssen sie diese auf die eine oder andere Weise bezahlen. Manchmal ist es günstiger, Oracle zu bezahlen, als den Code selbst zu schreiben. Manchmal ist kommerzieller, nicht offener Quellcode sinnvoll. Die Fakten sprechen für sich.

Das Obige sind die 8 MySQL-Fallen, die gesagt werden müssen. Weitere verwandte Inhalte finden Sie auf der chinesischen PHP-Website (www.php.cn)!