Frage zum Wiki-Artikel „PHP MySQL API“

[dedlfix]

Tach!

Auch ich würde nicht "je nach Anwendungsfall" sondern "nach Vorliebe" nehmen, weil funktional sich mysqli und PDO nicht viel nehmen, jedenfalls nicht für die Anwendungsfälle der Zielgruppe. Für bestimmte, eher selten verwendete Dinge braucht man mysqlis auf MySQL zugeschnittene Funktionalität. PDO ist eher als einheitliche Schnittstelle für mehrere DBMS als für die Verwendung bei datenbankspezifischen Eigenheiten.

Eine Umstiegshilfe findet sich unten.

Unten, oben, hier, dort ... sind alles keine gescheiten Linkbezeichnungen. "Informationen dazu in der Umstiegshilfe." wäre schon etwas besser.

Abkürzungen und Fachbegriffe sollte nochmal betrachtet werden, ob man da nicht noch anfängerfreundliche Kurzerklärungen/Übersetzungen hinzufügen kann. Ist ja nicht jedem geläufig, was zum Beispiel API heißt.

Maskieren und sprintf(): Ich würde da nicht noch eine Variable erstellen, in der lediglich die maskierte Variante steht. Zumal $username dann auch fachlich fraglich ist, weil es ja $escaped_username ist. sprintf() hat dann auch nicht ganz so viel Sinn. Besser:

$query = sprintf("SELECT firstname, lastname FROM users WHERE usergroup = '%s'",
             mysqli_real_escape_string($mysqli, $_POST['usergroup']));

mysqli_set_charset() will nicht nur den Kodierungsnamen ohne Bindestrich haben, es will auch nur die im Handbuch festgelegten Namen haben. "iso-8859-1" ist zum Beispiel nicht gültig, auch nicht ohne Bindestrichen.

Vor jeder Kommunikation zwischen Anwendung und Datenbank müssen alle Daten für die Datenbank aufbereitet werden.

Nö, müssen sie nicht. Nur für das Einbetten in den Statement-String. Im DBMS stehen sie ja nicht aufbereitet drin, sondern ... ganz anders - wie auch immer das DBMS sie speichert. Dem würde auch widersprechen, dass sie bei Prepared Statements nicht "für die Datenbank" aufbereitet werden müssen.

Die Schachtelung bei Fehleraufkommen müsste noch etwas sinnvoller gestaltet werden. Momentan ist das alles linear. Das lässt sich zwar besser unterbrechen, um Dinge zu erklären, aber im realen Leben kann man ja nicht (ungestraft) einfach weitermachen, wenn ein Verbindungsfehler oder einer bei einer vorhergehenden Funktion/Methode aufgetreten ist.

try-catch kann seinen Vorteil auch viel besser ausspielen, wenn nicht jeder Fehler einzeln gefangen und behandelt wird, sondern wenn diese Behandlung am Ende steht. Muss natürlich je nach Sinnfälligkeit gegenüber dem Anwendungsfall betrachtet werden, aber im Allgemeinen reicht ein catch-Block am Ende des gesamten Vorgangs (oder mehrere, wenn unterschiedliche Exceptiontypen separat gefangen werden sollen).

mysql_real_escape_string() kann zwar theoretisch einen Fehler zurückgeben, aber praktisch tritt das nicht auf, wenn man eine Verbindung geöffnet hat. Deswegen verwendet man das üblicherweise ohne Fehlerbehandlung.

Änderungen dürfen niemals am Produktivsystem durchgeführt werden!

Dürfen schon, verbietet ja kein Gesetz. Also "sollten" oder eine andere als Empfehlung formulierte Variante.

dedlfix.