Aktualisiert (Mittwoch, den 24. Februar 2010 um 15:07 Uhr) Geschrieben von: Johannes Schlimm Donnerstag, den 04. Februar 2010 um 18:51 Uhr

Wie angekündigt also nun ein paar kritische Anmerkungen zu PHP und/oder MySQL - ohne Anspruch auf Vollständigkeit:

1. Die einfache Erlernbarkeit ist relativ. Und stimmt vielleicht auch nicht mehr so ganz. Denn die mit PHP 5.x eingeführte stringentere Objektorientierung macht die Lernkurve schon etwas steiler. In Anlehnung an den Berliner Bürgermeister "Und das ist auch gut so!" Nicht unbedingt die Lernkurve, sondern die Möglichkeit der konsequenteren Objektorientierung. Die hat aber bei einer interpretierten Skriptsprache so ihre Schattenseiten. Jedenfalls kann man feststellen, dass immer mehr davon Gebrauch gemacht wird, wie z.B. beim Zend Framework, über das ich auch schon einmal hier gelästert habe, und das auch ein gutes Beispiel dafür ist, wie man PHP schön ausbremsen kann.
2. Ähnlich wie früher für Visual Basic, gilt für PHP, dass es vielen Leuten ermöglicht zu programmieren, die sonst davor zurückschrecken würden. Allerdings sind die Resultate oft erschreckend, wenn man sich den Quellcode anguckt. Ähnlich wie es bei Visual Basic der Fall war. Man muss der einfachen Möglichkeit, etwas zusammen zu hacken, bewusst wiederstehen und eine gewisse Selbstdisziplin aufbringen. Damit erstens kein unwartbares Gemenge dabei herauskommt, und zweitens sich keine Sicherheitslücken einschleichen. Gerade was Sicherheitslücken angeht, ist es sehr einfach möglich ruckzuck scheunengroße Löcher zu produzieren. Die kann man natürlich auch mit anderen Programmiersprachen "zaubern", aber es gibt doch einige Unterschiede. So enthält z.B. die ASP.NET Runtime zumindest Mechanismen, um automatisch XSS-Attacken abzufangen. Und zwar auch dann, wenn der Programmierer diese Gefahr komplett  "vergessen" hat.
3. Es lässt sich bei weitem nicht jedes x-beliebige Projekt mit Shared Hosting-Angeboten betreiben. Da gibt es einerseits manchmal Einschränkungen seitens des Providers, um die Sicherheit zu erhöhen. Andererseits reichen oft die zugestandenden Arbeitsspeicher- und Skriptlaufzeitbeschränkungen nicht aus. Das betrifft natürlich nicht nur PHP. Aber gerade weil es so oft bei Shared Hosting als einzige Möglichkeit zur Verfügung steht, sollte man sich dessen bewusst sein.
4. Gerade die Tatsache, dass PHP bei Facebook zur Anwendung kommt, scheint landläufig ein Beleg dafür zu sein, dass PHP auch für richtig "fette" Websites eine prima Sache ist. Wer dass glaubt, sollte wissen, dass Facebook einige Probleme damit hatte, und mit einer ziemlich ungewöhnlichen Maßnahme darauf reagiert hat, siehe auch diesen Beitrag im Facebook Developer Blog . Kleines Detail am Rande: Facebook soll über 30.000 Server betreiben, um die Last zu buckeln!
5. Nun zu einer für viele unglaublich anmutenden Tatsache: PHP unterstützt nativ nicht UTF-8! Ja, immer noch nicht! Man muss unglaubliche Verrenkungen anstellen, um sowohl mit UTF-8-Datenquellen als auch der HTML-Ausgabe, als auch programmierten Algorithmen, die auf Zeichenketten arbeiten, keinen Schiffbruch zu erleiden. Darüber könnte hier seitenlang geschrieben werden. Das haben andere aber auch schon gemacht, deswegen bitte z.B. hier bei Gerd Riesselmann nachlesen. Ich bin den Entwicklern der Joomla!-Community sehr dankbar, dass sie dieses Problem in den Griff bekommen haben!
   Auch wenn es altertümlich anmutet, wähle ich aus einigen guten Gründen bei der Entwicklung von PHP-Webanwendungen (abseits Joomla!) nach wie vor den Zeichensatz ISO-8859-1. Es sei denn, es ist wirklich unvermeidbar, UTF-8 zu verwenden:
   
   • ISO-8859-1 (alias Westeuropäisch) ist der native Zeichensatz von PHP. Selbst in der neuen 5.3er-Version. Dadurch ist es deutlich performanter, als einen anderen Zeichensatz zu verwenden
   • Die MySQL-Anbindung ist damit unproblematisch. Zu diesem Punkt sei nochmals auf den Artikel von Gerd Riesselmann verwiesen.
   • Sofern es eines Tages doch noch die - immer wieder angekündigte und wieder verschobene - PHP-Version 6 geben wird, die mit nativem UTF-8-Support versehen sein soll, könnte es sein, dass sämtliche vergangenen Verrenkungen um UTF-8 herum obsolet geworden sind. Sprich: Um Performancenachteile auszubügeln, wäre damit zu rechnen, dass an etlichen Stellen Quellcode (erneut) geändert werden muss. So etwas provoziert man nicht ohne guten Grund. Zumal ich damit rechne, dass aufgrund der Vielzahl der sonst davon Betroffenen, eine gangbare Lösung für eine Umstellung angeboten wird. OK, richtig sicher bin ich mir in diesem Punkt nicht.
6. Das am häufigsten mit PHP eingesetzte Datenbank-Management-System ist MySQL. Weil beides kostenlos ist. Oder? Hm. Kann man so nicht wirklich sagen. Zwar bieten Provider MySQL vorinstalliert an, aber für Entwickler gibt es einen Fallstrick: Sofern man Software mit MySQL vertreibt, ist es kostenpflichtig. Darauf hat mich MySQL auch ungefragt telefonisch hingewiesen. Ja, tatsächlich: Ich erhielt eines Tags einen Anruf, dessen einziger Zweck es war, auszuhorchen, ob man nicht mit etwas Nachdruck eine kostenpflichtige Lizenz an den Mann bringen könne, aufgrund der geltenden Lizenzbestimmungen. Liegt übrigens eine Weile zurück und war vor der Übernahme durch Oracle. Man stelle sich vor, Microsoft würde ungefragt bei einem anrufen. Was gäbe das für einen Aufschrei!
   Abgesehen davon - ich will hier aber nicht wieder auf den Artikel von Gerd Riesselman eingehen - gibt es ein paar Probleme mit MySQL, auch abseits Zeichensatzkonvertierungen: Die MyISAM-Variante, die bei Shared Hosting oft die einzige zur Verfügung stehende MySQL-Engine ist, unterstützt keine Transaktionen! Auch aus traditionellen Gründen, weil eben lange Zeit nicht unterstützt, werden häufig keine echten Foreign Keys, also Fremdschlüssel, eingesetzt. Die gibt es aber, sowie auch Transaktionen, mit der InnoDB-Variante.
   Nicht zuletzt wegen Ungereimtheiten der 5.1er Version, bei der man sich gründlich überlegen sollte, ob man sie überhaupt einsetzt, gibt es mittlerweile die "Forks" Drizzle und MariaDB. Es könnte einem eigentlich egal sein, dass MySQL nun zu Oracle gehört. Sofern es keine negativen Konsequenzen hat. Nun, man wird sehen.
   Jedenfalls sollte nicht unerwähnt bleiben, dass es auch in der Verbindung mit PHP DBMS-Alternativen gibt: Z.B. das frei verfügbare PostgreSQL, oder - warum auch nicht - auf Windows-Systemen die kostenlose Express-Version von SQL Server, von der man im Bedarfsfall auf die Vollversion upgraden kann. Aus eigener Erfahrung kann ich sagen, dass PHP mit SQL Server ein flottes Gespann ist.