Hallo dedlfix,

auch Dir herzlichen Dank für Dein Feedback!

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.

Werde ich ändern.

Eine Umstiegshilfe findet sich unten.

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

Hmm. Und das, wo ich mich immer über sowas aufrege. Darf natürlich nicht sein, wird geändert!

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.

Werde ich auch nochmal im gesamten Artikel drauf achten. Ich hab schon versucht, bei möglichst allen Vorkommen von sowas auf das Glossar zu verlinken (wo ich dann natürlich die fehlenden Einträge noch hinzufüge). Aber dann muss ich da wohl nochmal gucken. Meinst Du, das direkt im Artikel zu erklären ist besser als den Weg über das Glossar zu gehen?

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']));

Ok, kann ich auch gerne so machen. So würde ich das normalerweise auch machen. Ich glaube ich wollte das einfach zu sehr „nach Lehrbuch“ und strukturiert machen, dass mir gar nicht mehr aufgefallen ist, dass man das so eigentlich gar nicht macht.

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.

Den Hinweis füge ich mit ein.

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.

Ja, ist richtig. Muss ich umformulieren. Das war dann doch wohl zuviel des Guten, wie ich immer wieder auf den Kontextwechsel aufmerksam machen wollte. Hatte Rolf ja auch schon angemerkt.

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.

Hättest Du da einen Vorschlag? Ich wollte das halt so „offen“ wie möglich halten, da das ja tatsächlich davon abhängig ist, was man gerade vorhat. Sollte ich sonst evtl. weitere geplante Artikel hintenanstellen und erstmal ein Anfängertutorial mit ein paar konkreten Beispielen schreiben, auf das man dann verweisen kann? Ich denke, das könnte man in so einem Rahmen wahrscheinlich etwas besser erklären. Oder was meinst Du?

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).

Ja, so verwende ich try-catch auch üblicherweise. Hier hatte ich auch tatsächlich zuerst nur einen try-catch-Block, hab es dann aber in zwei aufgeteilt. Ich habe mir dabei gedacht, dass so etwas deutlicher wird, dass bei einem Fehler beim Verbindungsaufbau sicherlich eine andere Fehlerbehandlung stattfindet als wenn eine Datenbankabfrage schief geht. Gleiches Problem wie zuvor, zu sehr in „Kategorie Lehrbuch“ gedacht? Also lieber nur einen Block verwenden?

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.

Hab ich selbst auch noch nie überprüft :-) Wohl ebenfalls das Problem, dass ich es zu gut gemeint habe. Kommt raus.

Ä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.

Ja, hört sich etwas übertrieben an ;-) Wird geändert.

Vielen Dank und Gruß
Dennis