mySQL für Umsteiger

Dieser Post wurde aus meiner alten WordPress-Installation importiert. Sollte es Darstellungsprobleme, falsche Links oder fehlende Bilder geben, bitte einfach hier einen Kommentar hinterlassen. Danke.

Öffnet man einem Einsteiger, der nur PHP und mySQL kennt, langsam die Augen für dass, was noch alles so da draußen ist, hört man immer wieder das gleiche ungläubige Staunen, wenn er ein neues CPAN-Modul oder eine tolle Datenbankfunktion entdeckt (die für SQL-Kenner eigentlich Standard ist). In der schönen neuen Welt abwärtskompatibler Programmiersprachen und professioneller Datenbanken gibt es viel zu entdecken, mit dem die Entwicklungszeit drastisch reduziert werden kann - und der Umsteiger kann selbst kaum glauben, wie effizient und schnell er auf einmal programmieren kann.

Schwieriger wird es, wenn der Weg in die andere Richtung gegangen werden soll und genau das steht mir bevor. Während alle SQL Server mit denen ich bisher intensiv gearbeitet habe, namentlich Sybase iAnywhere, Sybase ASE und Postgres, sehr ähnlich waren, schlägt mySQL sehr oft aus dem Rahmen. Bisher habe ich die mittlerweile von Oracle geschluckte Datenbank nur in kleineren Projekten benutzt und es meistens früher oder später bereut.

Von den Unterschieden bei intensiver Nutzung wusste ich hauptsächlich aus Erzählungen ehemaliger PHP-mySQL-Jünger, die mittlerweile Microsoft SQL (weitgehend identisch zu Sybase ASE) oder andere "professionelle" Datenbanken nutzen und das nicht SQL-konforme mySQL möglichst meiden.

Jetzt ist allerdings der Punkt gekommen, an dem ich nicht mehr anders kann: Für ein richtig großes Projekt ist mySQL zwangsweise notwendig - nicht meine Entscheidung, aber nicht zu ändern. Als Vorbereitung habe ich nach einer Anleitung für Umsteiger auf mySQL gesucht und wurde bei Little Idiot fündig.

Leider strotzt bereits die Einleitung des Kapitels nur so von Unkenntnis großer Datenbanken und - so viel belegen meine Erfahrungen der Vergangenheit ebenso wie Erfahrungsberichte verschiedener Profis - einer massiven Überschätzung von mySQL.

Genau in dem Stil geht es weiter: "Foreign Keys", auf Deutsch Fremdschlüssel, sichern die Datenbankkonsistenz. Diese lässt sich zwar auch applikationsseitig prüfen und sicherstellen - allerdings verbunden mit sehr viel Mehraufwand und vielen zusätzlichen SQL-Abfragen, die den Datenbankserver wieder mehr belasten. Richtig eingesetzt sind sie ein sehr mächtiges Werkzeug, benötigen allerdings - zugegeben - etwas mehr Leistung als man ohne sie bräuchte. Leider sind all die angeführten Beispiele ziemlicher Quatsch, denn wenn man weiß was man tut, hindern sie an keiner der dort beschriebenen Aufgaben.

CREATE-Skripte werden ohnehin von Tools wie "Sybase Central", "PgAdmin" oder vom Microsoft SQL Manager erstellt und bei Bedarf von Hand angepasst, dabei sind alle Abhängigkeiten allerdings bereits erledigt, denn die Tools sortieren die Skripte entsprechend.

Die folgenden Seiten erhöhen die Fehlerdichte immer weiter, zwischenzeitlicher Höhepunkt: "Views sind nicht weiter, als temporäre Tabellen". Ich konnte mir mit großer Mühe verkneifen, jede einzelne Seite zu korrigieren - bis hier. Ein View ist keine Tabelle, sondern einfach gesagt ein (meist sehr komplexer) SELECT der serverseitig abgelegt wird, in einfachsten Fall könnte dieser lauten "SELECT foo.*,bar.* FROM foo JOIN bar ON foo.some_col = bar.id" und würde bei einem "SELECT * FROM view_name" einfach beide Tabellen zusammenführen. Stellt man sich die VIEW-Anweisung jetzt als 10 Zeilen lange SQL-Abfrage vor, ist es für den Programmierer einfacher, einen "SELECT * FROM view_name" auszuführen und die Datenbank kann sich intern bereits bei der Erstellung des VIEWs darauf vorbereiten und wird schneller antworten, als sie es könnte wenn die komplexe Anweisung jedes Mal vollständig vom Client geschickt werden würde.

Zusammenfassend kann man aus dieser Anleitung entnehmen, dass mySQL (nach Kenntnis des little idiot) einige Standards nicht unterstützt:

• Foreign Keys
• Trigger
• Union
• Locking (nur teilweise)
• Cursors
• Views
• Transaktionen (COMMIT/ROLLBACK)
• Subselects
• Joins (nur teilweise)
• Verschlüsselte Übertragung von Daten
• Stored Procedures
• Verteilte Datenbanksysteme und Skalierung (teilweise)
• Datenbank-Replikation (teilweise)
• Große Datenbanken > 2 Gigabyte

Die Detailbeschreibungen sagen vom Prinzip her aus: mySQL kann das nicht, aber das ist nicht schlimm, weil diese Funktion ohnehin jede Datenbank töten würde oder sie gar nicht gebraucht wird. Okay, also werde ich jetzt Autohändler und erkläre den Kunden "ABS, Airbags und Türen haben wir nicht, aber das brauchen sie sowieso nicht..."

Leider habe ich bisher keine andere Hilfe für Umsteiger auf mySQL gefunden :-(