Home > Archiv > PHP mit MySQL ist populär. Aber...

PHP mit MySQL ist populär. Aber...

Geschrieben von   admin on    Februar 4, 2010

Wieso "aber"?

Nun, es stimmt: PHP ist vermutlich die am häufigsten eingesetzte Sprache, um Webanwendungen zu schreiben. Vermutlich liegt es an folgenden Gründen, denen ich aber nachfolgend etwas auf den Zahn fühlen werde:

  1. PHP gilt als einfach zu erlernen.
  2. PHP gibt es bei fast jedem Wald- und Wiesen-Provider. Auch bei Shared-Hosting-Paketen für wenig Geld. Sofern es kein reiner "Visitenkarten"-Auftritt ist, gehört PHP praktisch zum Mindeststandard. OK, kann man so stehen lassen. Allerdings gibt es da oft Beschränkungen.
  3. Man hat oft den Eindruck, dass Sites beliebiger Größenordnung damit betrieben werden. Ist das nicht ein Beleg dafür, dass es für alle Größenordnungen taugt? Frei nach einem sowjetischen Radiosender: "Im Prinzip ja. Aber...".
  4. Es gibt ja schließlich z.B. PHP-CMS, die mit UTF-8 arbeiten. Das wird wohl kein Problem mehr sein. Oder doch? Ähm, im Jahr 2010? Gibt's doch gar nicht! Doch gibt's!
  5. Nach weit verbreiteter Meinung steht mit dem Gespann aus PHP und MySQL eine gut funktionierende, solide und kostengünstige Umgebung zur Verfügung

Bevor ich nun zu einem Rundschlag gegen PHP und/oder MySQL aushole, möchte ich klarstellen, dass ich aus gutem Grund trotzdem Dienstleistungen auf diesem Gebiet anbiete. Mir kommt es - aus persönlicher Überzeugung - darauf an, dass Kunden, und solche die es werden könnten, wissen, dass sie es mit jemandem zu tun haben, der mit ihnen Klartext redet und nichts beschönigt. Und schließlich ist es auch erst das Wissen um vorhandene Schwächen, was es ermöglicht, wirklich fundiert vorgehen und beraten zu können.

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 und des Zend Framework sehr dankbar, dass sie dieses Problem in den Griff bekommen haben!
    Folgendes sollte man wissen:
    • 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.
  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.

Aber auch in neuerer Zeit gibt es bei PHP Entwicklungen, über die man nur den Kopf schütteln kann:

  • Mit PHP 5.3.0 wurden Namespaces eingeführt. OK. Aber warum zum Henker musste man ausgerechnet den Backslash, also \ als Trenner zwischen Namespace und Klassennamen nehmen? Das werde ich nie begreifen. Es stinkt förmlich nach Problemen.
    Praktischerweise führt diese Entscheidung dazu, dass die meisten autoload-Mechanismen, die z.B. Klassenbenennungen nach dem PEAR- bzw. Zend Framework-Schema behandeln, unter Windows ohne Probleme auch damit zurechtkommen, wenn der Namespace eine eigene Verzeichnisebene bildet. Was vermutlich die Regel sein dürfte. Z.B. Foo\Oberklasse_Unterklasse wird korrekt abgebildet auf Foo\Oberklasse\Unterklasse.php. Übrigens: Auch wenn auf Foo\Oberklasse/Unterklasse.php abgebildet wird - der zweite Schrägstrich also ein gewöhnlicher ist, funktioniert dies bei Windows. Aber eben nur bei Windows. Auf *X-Systemen, die für gewöhnlich nicht mit \ als Verzeichnistrenner zurechtkommen, müssen autoload-Mechanismen zur Berücksichtigung von Namespaces abgeändert werden. So wurden Portabilitätsprobleme im wahrsten Sinne des Wortes "vorprogrammiert".
  • Eigentlich sollte man, solange man den PEAR- bzw. Zend Framework-Konventionen zur Benennung von Klassendateinamen folgt, seit PHP 5.1.2 ganz auf einen selbstgeschriebenen autoload-Mechanismus verzichten können, da spl_autoload() als Default-Implementierung dafür zur Verfügung steht. Nun steht bei der entsprechenden Dokumentation im PHP Manual:  "By default it checks all include paths to contain filenames built up by the lowercase class name appended by the filename extensions .inc and .php." Moment! "lowercase class name"? Aber PEAR und Zend Framework, und alle die sich an deren Benennungskonvention halten, benutzen doch einen Großbuchstaben als jeweils erstes Zeichen in der Klassenhierarchie! Und das eben auch beim Verzeichnis- bzw. Dateinamen! OK, das ist bei Windows kein Problem. Denn auch Dateien die nicht dem Schema mit "lower class names" folgen, werden dort gefunden. Aber nicht auf *X-Maschinen. Dort wird im Dateisystem ja zwischen Groß- und Kleinschreibung unterschieden. Autsch!! Wer der PEAR- / Zend Framework-Benennungskonvention folgt, was eindeutig die am weitesten verbreitete Benennungskonvention ist, kann die schnelle Default-Implementierung also nicht benutzen, wenn alles portabel bleiben soll. Dieser "Feature-Bug" ist ohne Frage ein Sockenschuss der Güteklasse 1A!

Das soll an Informationen zu dieser Thematik erst einmal reichen. Im Prinzip gäbe es noch reichlich darüber zu schreiben, aber ich verweise auf die folgenden Links:

Wenn also PHP und/oder MySQL so schlecht sind, warum biete ich dann Dienstleistungen auf diesem Gebiet an?

Es gibt eben auch gute Gründe für PHP und/oder MySQL:

  • Der hohe Grad der Verbreitung bedeutet eben auch, dass man sowohl bei Recherchen zur Lösungen von Problemen, als auch bei Skripten und Bibliotheken, CMS usw. eine Riesenauswahl hat, die so wohl einmalig ist.
  • Kunden gehen ein begrenztes Risiko ein, wenn Sie eine Webanwendung mit PHP und/oder MySQL erstellen lassen, da es deutlich einfacher ist, dafür andere Entwickler zu finden, falls die Zusammenarbeit mit einem Entwickler oder Firma nicht so gut klappt. Allerdings ist dann auch zu wünschen, dass der Quellcode gewissen Mindestansprüchen genügt, damit so ein Wechsel auch relativ problemlos von statten gehen kann.
  • Die Alternativen sind auch nicht durchweg ohne Probleme. Ich habe daher vor, auch anderen Umgebungen hier auf den Zahn zu fühlen.

Blogbeiträge:

 Tags:

Blog MySQL PHP

Kommentare

Kommentar schreiben



(Ihre E-Mail-Adresse wird nicht angezeigt.)


Ungültiger Sicherheitscode

Bitte klicken Sie das Bild an, um einen neuen Sicherheitscode zu laden.