Seitenanfang

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.


PHP und mySQL sind sind klassische Einstiegsdroge in die Web-Programmierung. Im Gegensatz zu den am Straßenrand verkauften Pülverchen & Co. kann es in der Web-Programmierung allerdings nur besser werden - womit allerdings auch das Suchtpotential zunimmt. Schwieriger wird es, wenn man von der anderen Seite kommt und sich auf mySQL umstellen muss.

Ö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 ganzen Texte zu den einzelnen Punkten kann man sich eigentlich sparen und auch bei einigen Punkten (wie Transaktionen, Skalierung, Replikation und Datenbanken >2 GB) bin ich ziemlich sicher, dass sie mittlerweile unterstützt werden.

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 :-(

 

5 Kommentare. Schreib was dazu

  1. Die Dokumentation ist meiner Meinung nach nicht auf dem aktuellen Stand. Ich selbst arbeite hauptsächlich mit MySQL und komme mit den Einschränkungen ganz gut klar. Außerdem unterstützt MySQL mittlerweile einige der Features. Bei Foreign Keys gibt gibt es aber tatsächlich ein ärgerliches Handicap. Es werden nur foreign key constraints zwischen Tabellen akzeptiert, welche die gleiche Datenbank Engine verwenden. Transaktionion gibt es nur mit InnoDB. Ansonsten bietet eine aktuelle MySQL Version alle genannten Features.

  2. Sid Burn

    Diese Liste ist aber etwas veraltet und stimmt zu großen Teilen nicht mehr. Diese Liste mag wohl noch für MySQL 4 stimmen, aber nicht mehr für MySQL 5. Das einzige was man bei MySQL beachten muss und was eigentlich gegen das Konzeot einer Datenbank geht sind die sogennanten Storage Engines.


    MySQL hat verschiedene Storage Engines die teilweise unterschiedliche Features unterstützen. Die Standard Storage Engine ist immer noch "MyISAM" und auf dieses stimmt oberes zu, allerdings sollte man diese Engine eigentlich überhaupt nicht mehr nutzen, meist ist die Performance auch besser als bei MyISAM, obwohl viele das gegenteil behaupten/glauben.


    Besser ist die InnoDB Storage-Engine. Und wie gesagt eigentlich ist es misskonzept das man sich bei einer Datenbank drum kümmern muss wie die Daten gespeichert werden, aber leider ist so MySQL nunmal aufgebaut. Ein weiterer Kritikpunkt. MySQL unterstützt ersteinmal alles an SQL, daher auch Fremdschlüssel beziehungen etc. und schluckt es einfach, auch wenn die unterliegende Storage-Engine es nicht unterstützt.


    Ansonsten hast du mit InnoDB ohne Probleme Fremdschlüssel, Union, Transaktionen, Subselects, Locking (Row Locking mit InnoDB), Views generell kann MySQL 5 ebenfalls, Joins (was sollte da nur teilweise gehen?).


    MySQL unterstützt Replikation. Master-Slave die asnychron ist. Ab MySQL 5.2? auch eine Master-Master Replikation. Ebenfalls gibt es noch den MySQL-Cluster der aber kostenpflichtig ist.


    Datenbanken über 2 Gigabyte sollten kein Problem sein, ich habs nicht ausprobiert, kann mir aber kaum vorstellen das dies noch eine gültigkeit hat. Wohl eher noch für MySQL 4 unter einem ext2 Dateisystem.


    Auch die "ON UPDATE" oder "ON DELETE" befehle funktionieren bei InnoDB einwandfrei. genauso werden Trigger, Stored Procedures etc. unterstützt.


    Wie gesagt, bei Informationen am besten immer auf das Datum achten. MySQL mag zwar einige Probleme haben, aber mit MySQL 5 ist die Datenbank nicht mehr so schlecht. Ebenfalls darauf achten für welche Storage Engine die beschreibung ist. Da musst du bei MySQL drauf achten. Man sollte heutzutage InnoDB nehmen.


    MyISAM hat als weitere nachteil auch probleme wenn die Datenbank abstürzt, also nicht sauber beendet. meistens sind die Datenbanktabellen dann defekt, daher wie gesagt immer auf InnoDB achten.

  3. Sebastian

    Wie schon geschrieben, bei einigen der "Features" war ich mir auch recht sicher, dass sie mittlerweile unterstützt werden. Aufgeregt haben mich vielmehr die Beschreibungen, denn sie verkünden so inbrünstig das Apple-Prinzip: Alles, was nicht funktioniert, ist ein Feature, denn unsere User wollen das gar nicht haben.

  4. Sid Burn

    Zu dem Apple Konzeot fällt mir gerade diese Seite ein. Archviert auf archive.org von der Dokumentation von MySQL die beschreibt warum man keine Foreign Keys benötigt. Zum lachen ist diese allemal zum gebrauchen. Nachdem dann MySQL mit InnoDB auch Foreign Keys unterstütze wurde diese Seite dann leise entfernt. Aber es gibt ja archive.org!


    http://web.archive.org/web/20010127081400/mysql.com/doc/B/r/Broken_Foreign_KEY.html

  5. thorsten mueller

    Aktuell ist die Version 5.5.5,Lies einfach die aktuelle Doku und aktualisiere deinen post.

Schreib was dazu

Die folgenden HTML-Tags sind erlaubt:<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>