Frage zum Wiki-Artikel „PHP MySQL API“

[Rolf b]

Hallo Dennis,

ich finde den Artikel als Einstieg prima. Du hast Dir viel Arbeit gemacht. Man muss natürlich grundsätzlich immer überlegen, ob ein solches Werk im Kontext von SelfHTML sinnvoll ist oder ob man auf gute, fertige Artikel im wilden weiten Web verweisen kann. Ob sich viel Arbeit für ein "Me too" Produkt lohnt, muss man immer gut überlegen. Aus meiner Sicht (aber das ist meine Privatmeinung) liegt der Schwerpunkt des Wiki im Browser, d.h. HTML, CSS und Javascript. Da steht SelfHTML in harter Konkurrenz zu MDN, was das Label "beste Doku" angeht, und ist im Rückstand (mangels Manpower?). Ob man dann ein weiteres Feld eröffnet, statt das bestehende Feld zu stabilisieren, ist eine Überlegung wert.

Unter der Annahme, dass die Überlegung zu Gunsten einer PHP Einführung endet, hätte ich folgende Hinweise.

• die Formulierung "die Auswahl der API erfolgt in Bezug auf den konkreten Anwendungsfall" würde ich so nicht stehen lassen. "Anwendungsfall" bezeichnet für mich die fachliche Anforderung, die umzusetzen ist, und da sind mysqli/proc, mysqli/oo und PDO gleichwerting. Performance ist ebenfalls kein Kriterium, weil alle Anbindungen leichtgewichtige Hüllen um den eigentlichen C-Treiber sind. Auswahlkriterium ist eher die Vorliebe des Programmierers. Wenn man ein PHP-Programm objektorientiert aufzieht, wird man auch die OO-Schnittstelle von MySQLi nutzen wollen, oder gleich PDO. Wenn man ohne Objekte arbeitet bzw. von mysql auf mysqli umstellt, verwendet man die prozedurale Kapsel.
• mysql wurde abgelöst, weil es Sicherheitslücken hat? Hast Du dafür einen Quelle? Hier steht, was in mysqli besser wurde, aber von geschlossenen Sicherheitslücken steht da nichts. Auf entwickler.de habe ich einen Hinweis vom PHP 5.3 Release Manager - Johannes Schlüter - gefunden: The old mysql extension, ext/mysql, is old. The code goes back to the early days of PHP and MySQL and embraces some bad design decisions. For example if no explicit connection resource is passed all functions will try to use the last connection which was being used..
• die prozedurale Variante von mysqli weicht bei connect etwas von der OO-Schicht ab, new mysqli() liefert immer ein mysqli-Objekt, aber mysqli_connect liefert FALSE wenn ein Fehler auftritt. Deswegen bekommen mysqli_connect_errno() und mysqli_connect_error() auch keinen Parameter (siehe Doku, da steht void). Und um zu prüfen, ob $link = mysqli_connect(...) fehlschlug, soll man if (!$link) testen. (siehe Beispiel hier)
• sprintf: Ist das in PHP das Mittel der Wahl? Ich kenne hauptsächlich Verkettungen per . Operator oder string parsing ("Hallo $dings")
• In der mysqli-Beschreibung sprichst Du korrekt vom Escaping für den Kontextwechsel. Aber im PDO Beispiel verwendest Du ein prepared statement - wo man nicht escapen muss. Deshalb ist es meiner Meinung nach falsch, dort von einem Kontextwechsel zu sprechen. Er ist hier nicht nötig, weil die Parameter nicht ins SQL eingebettet werden. Sie bleiben in ihrem eigenen Kontext erhalten. Statt dessen sollte darauf hingewiesen werden, dass prepared statements wegen der SQL Parameter kein Escaping benötigen.
• Du könntest darauf hinweisen, dass auch mysqli prepared statements unterstützt (aber schlechter, weil es keine benannten Parameter gibt) und dass man in PDO auch eine Funktion für Escaping im Kontextwechsel hat, wenn man keine prepared statements verwenden will (PDO::quote). Wenn man das vollständig zeigen will, muss man das Beispiel allerdings fünfmal statt dreimal bringen :)

Rolf