Die haufigsten MySQL Fehler von PHP Entwicklern

Die häufigsten MySQL-Fehler von PHP-Entwicklern

Die Welt der Datenbankentwickler ist geheimnisvoll, kryptisch und von großer Expertise geprägt. Echte Datenbankdesigner umgibt der Nimbus des Unerklärlichen. Auf der anderen Seite stehen die herkömmlichen PHP-Entwickler, die zumeist für ihre Applikationen ebenfalls eine Datenbank einsetzen müssen und aus alter Verbundenheit MySQL wählen. Dabei gehen sie in der Regel so pragmatisch wie möglich vor. Unnötiger Know-How-Overhead wird beiseite gelassen. Ein paar Dinge gilt es aber doch zu beachten.

Fehler #1: Alternativen zu MySQL werden nicht betrachtet

Der häufigste MySQL-Fehler, den PHP-Entwickler heutzutage machen, ist, dass sie relativ unreflektiert überhaupt MySQL verwenden. Dabei gibt es je nach Anwendungszweck besser geeignete, dabei auch freie Alternativen.

Man kann es sich heute kaum vorstellen, aber MySQL war zunächst die Basis für Twitter. Auch andere große Projekte nutzten und nutzen noch heute MySQL, allen voran Facebook und WordPress.com. Dabei sind Alternativen verfügbar, die gerade bei Projekten wie WordPress.com, große Vorteile versprechen.

Beispielhaft sei hier die NoSQL-Datenbank Apache Cassandra genannt. Cassandra wurde ursprünglich von Facebook entwickelt. Mittlerweile nutzen es auch Twitter und Digg, um nur große Verwender zu nennen. Basierend auf technischen Ansätzen von Google und Amazon speichert Cassandra Daten so, wie sie später auch abgerufen werden, also vorsortiert. Man kann sich vorstellen, dass eine vorsortierte Tabelle performanter ist, als eine, die zunächst zur Laufzeit mit Sort By in Form gebracht werden muss. Dies gilt umso mehr, je größer der zu sortierende Datenbestand ist.

Cassandra macht nur Sinn, wenn es direkt zu Beginn in die Anwendungsentwicklung integriert wird, da die Daten von der Anwendung via API manipuliert werden. Verwaltungsoberflächen, wie etwa bei MySQL stehen nicht zur Verfügung. Ein weiterer Vorteil von Cassandra ist die einfache Skalierbarkeit. Mehr Rechenpower erforderlich? Einfach einen weiteren Rechner anschließen, alles weitere regelt Cassandra selber . Der größte bekannte Cluster (Zusammenschluss mehrerer Rechner zu einer Datenbank) wird nach wie vor von facebook betrieben und umfasst über 150 Rechner.

Wer sich näher mit Cassandra befassen will, sollte meinen Beitrag „Was kann die NoSQL-Datenbank?“lesen, den ich vor einigen Wochen für das Dr. Web Magazin schrieb. Darin kommen auch noch einige andere Lösungsansätze zum Zuge.

Eine weitere Leseempfehlung ist der Artikel „NoSQL – Neues Denken in der Datenbankwelt“ aus t3n Magazin Nr. 19.

Fehler #2: Select-Abfragen werden stets mit * durchgeführt

Verfechter dieser Vorgehensweise behaupten gern, das Setzen des Platzhalters sei im Grunde der effizienteste Weg der Datenbankabfrage, weil man im Verlaufe der Anwendung ohnehin alle Felder irgendwo braucht. Zudem sei es auf diese Weise einfach möglich, nachträgliche neue Felder ohne Reprogrammierung in der Anwendung zu benutzen.

Beide Aussagen sind falsch. Im ersten Fall kommt es zur Verschwendung von Arbeitsspeicher mit den daraus resultierenden Performanceverlusten. Von Effizienz keine Spur. Und die einfache Hinzunahme neuer Felder im Nachhinein funktioniert nur, wenn die MySQL-Instanz ohne Query-Cache betrieben wird. Ist der Query-Cache aktiviert, was gute Entwickler voraussichtlich tun, würde ein nachträglich hinzugefügtes Feld nicht einmal im Query-Ergebnis auftauchen, solange der MySQL-Server nicht neu gestartet wurde. Dabei sind regelmäßige Neustarts eher nicht die Regel.

SQL-Entwickler Joe Lango vertritt ebenfalls eine klare Meinung dazu.

Fehler #3: Bei der Datenbankdefinition wird latin als Charset gewählt

Ich bin nicht sicher, wie es heute am Tag ist, aber noch vor einiger Zeit wurde mir bei der Anlage einer MySQl_DB stets einer der latin-Zeichensätze angeboten. Hätte ich nicht aufgepasst und von Hand UTF-8 gewählt, was mir tatsächlich gelegentlich passiert ist, hätte ich mich später über ulkige Effekte, vor allem im Bereich der Sonderzeichen gewundert.

Unbedingt auf den Einsatz von UTF-8 muss geachtet werden, wenn eine Anwendung entwickelt wird, die über mehrere Kontinente funktionieren soll.

Aber: Wenn sichergestellt werden kann, dass die DB nur innerhalb eines Sprachraums verwendet wird und das Auftreten mehrerer Sprachen in den Datenspalten ausgeschlossen ist, sollte die passende ISO-Kodierung gewählt werden. UTF-8 benötigt für die Kodierung die bis zu dreifache Menge an Zeichen, was ein potenzielles Performanceproblem birgt.

Fehler #4: Bei der Wahl der Datentypen wird wenig wählerisch vorgegangen

Natürlich kann man ein Datum grundsätzlich in einem als String deklarierten Feld speichern. Nur macht das keinen Sinn. Probleme gibt es spätestens dann, wenn man mit dem Inhalt datumsbasiert weiter arbeiten will.

Deshalb: Immer den richtigen Datentyp verwenden. Bei Jan Schmager gibt es eine schöne Übersicht dazu.

Fehler #5: Backups der Datenbank werden nicht gemacht

Gut, ich räume ein, es handelt sich um ein ganz generelles Problem. Backups sind grundsätzlich Mangelware. Bei Datenbanken im Livebetrieb ist das allerdings besonders problematisch. Neben Bequemlichkeit als Grund für nicht gefahrene Backups kommt im Falle von MySQL hinzu, dass sehr große Datenbanken je nach Art des Zugriffs darauf, nicht unbedingt leicht zu sichern sind (Stichwort: Scriptlimits).

In diesem Dr. Web Beitrag habe ich massenhaft MySQL-Verwaltungstools vorgestellt, unter anderem auch die kostenlose Backuplösung MySQLDumper, die Schluss macht mit Scriptlimits.

Fehler #6: Uralte PHP MySQL-Funktionen werden genutzt

PHP war von Beginn an auf die Manipulation von MySQL-Datenbanken ausgelegt und brachte entsprechend früh die erforderlichen Funktionen mit. Mittlerweile gibt es Alternativen, die den Erfordernissen moderner Datenbank-Anbindung eher genügen. In vorderster Front stehen dabei die PHP-Extension mysqli (MySQL Improved), sowie die PHP Data Objects. Wer mit dem Zend Framework arbeitet, sollte dessen Data Abstraction Layer verwenden.

Fehler #7: Datenbankusern werden zu viele Rechte eingeräumt

Ich schätze, dass es eher Unkenntnis denn Bequemlichkeit ist. Jedoch habe ich schon sehr oft Datenbanken vorgesetzt bekommen, die aus der Anwendung heraus als Admin, respektive mit uneingeschränkten Rechten auf die DB zugreifen, obschon reine Lesezugriffe an den meisten Stellen ausreichend gewesen wären.

An dieser Stelle muss auch das Maskieren von Querystrings zur Vermeidung von SQL-Injections genannt werden. Eine Vorgehensweise, die ich selbst bei größeren Projekten eher selten zu Gesicht bekomme. Die Wikipedia stellt in ihrem Beitrag zu SQL-Injection unter dem Punkt PHP entsprechende Strategien vor.

Fehler #8: Die falsche Engine wird eingesetzt

Achtung! Dieser „Fehler“ kann Glaubenskriege los treten. Unter MySQL trifft man am häufigsten auf die Datenbankengines MyISAM und InnoDB, wobei MyISAM der Standard ist.

Welche Engine sollte man einsetzen?

MyISAM, also die Engine, die man wählt, wenn man nichts wählt, bietet Tabellen, die einfach aufzusetzen und schnell sind. Aber die wirkliche Besonderheit ist ihre Fähigkeit der Volltextsuche. Dafür unterstützt sie keine Transaktionen, sperrt bei Schreiboperationen immer die gesamte Tabelle und kann nach einem Serverausfall reparaturbedürftig werden.

InnoDB hat die genannten Nachteile nicht. Insbesondere unterstützt sie Transaktionen, sperrt bei Schreiboperationen nur die betroffene Zeile der Tabelle und ist auch bei etwaigen Serverausfällen fehlerresistenter. Dafür, und das wird bei vielen Anwendungen, wie etwa Blogs und Foren das Killerargument sein, ist sie nicht in der Lage, Volltextsuchen durch zu führen.

So kann die Faustregel lauten: Site mit viel usergenerated Content = MyISAM, Site mit Shopfunktionalität oder in anderer Weise finanzrelated = InnoDB

Habt Ihr weitere gängige Fehler oder Besonderheiten auf Lager? Wie geht Ihr bei der DB-Auswahl vor? MySQL stets und ständig oder gern auch mal was besser passendes?


Deprecated: Directive 'allow_url_include' is deprecated in Unknown on line 0