Datenbenkverbindung mit mysqli-Extension

[ChrisB]

Hi,

Hm, das verstehe ich halbwegs, aber wenn ich zB auf die Erklärung beim Traumprojekt schaue, dann kommt dort beim Punkt "Datensätze auslesen (Query Methode)" überhaupt kein "mysql_query" vor.

Doch, kommt es.
Nur nicht in der prozeduralen, sondern in der objektorientierten Variante - $db ist dort die Instanz der MySQLi-Klasse, und auf der wird die Methode query aufgerufen:
$ergebnis = $db->query( $sql );

Bei Prepared Statements entfaellt dies - weil der Befehlsteil der Query und die Daten auf getrennten "Kanaelen" zur Datenbank transportiert werden.

Ich traus mich fast nicht sagen, aber ich versteh nicht ganz, was Du meinst und von welchem Unterschied Du sprichst.

OK, noch mal gaaanz langsam:

Wenn du mysqli_query nutzt - egal ob prozedural oder objektorientiert - dann baust du dir dein SQL-Statement selber zusammen, und hast Befehl-Schluesselwoerter (wie SELECT, INSERT, ...) *und* deine Daten in einem String stehen:
INSERT INTO beispieltabelle001 (bt001_name, bt001_ort) VALUES ('blah', 'blubb')
blah und blubb waeren hier die Daten, die wir in die Tabelle einfuegen wollen. Da dies Strings im MySQL-Kontext sind, muessen sie innerhalb des Statements in Hochkommata (oder Anfuehrungszeichen) stehen.

So, jetzt sind diese Daten aber nicht fix, sondern dynamisch - sie koennten beispielsweise aus einem Formular kommen. Und jetzt sei mal der erste Wert nicht blah, sondern O'Connor - dann erhielten wir folgendes Statement:
INSERT INTO beispieltabelle001 (bt001_name, bt001_ort) VALUES ('O'Connor', 'blubb')
Du siehst, schon am Syntaxhighlighting hier, dass das mit den Hochkommata jetzt Probleme macht - der MySQL-Textstring endet jetzt schon wieder nach dem 'O', und danach folgt jetzt etwas, was keine gueltige SQL-Syntax mehr darstellt - also haben wir da ein Problem. Und deshalb muessen wir unseren Wert O'Connor fuer den Kontext MySQL behandeln - und zwar so, dass das Sonderzeichen ' durch einen vorgestellten \ "maskiert" wird:
INSERT INTO beispieltabelle001 (bt001_name, bt001_ort) VALUES ('O\'Connor', 'blubb')
Damit hat das Zeichen ' hier nicht mehr die Bedeutung "String ist zu Ende", und damit ist das Statement fuer den MySQL-Parser wieder verstaendlich.
(Das Maskieren machen wir aber nicht selber "per Hand" - sondern dafuer gibt's die Funktion mysqli_real_escape_string - die weiss, welche Zeichen im Kontext eines MySQL-Statements Sonderbedeutung, und behandelt sie entsprechend.)

So, das ganze Problem haben wir aber nur, weil wir bei dieser Art, eine Query an MySQL zu uebergeben, Befehl und Daten "in einem" an MySQL uebergeben - und dessen Parser muss erst mal analysieren, was davon eigentlich Befehl, und was Daten sind.

Bei den Prepared Statement wird das getrennt - erst mal wird der eigentliche Befehl uebergeben,
INSERT INTO beispieltabelle001 (bt001_name, bt001_ort) VALUES (?, ?)
Das ist fuer den Parser ganz eindeutig, "Aha, ein INSERT-Statement, in dem zwei Platzhalter vorkommen, an denen ich spaeter irgendwelche Daten einsetzen muss".
Das Statement ist jetzt analysiert, uebersetzt, vorbereitet - auf Englisch "prepared".

Ueber das Binding der Variablenwerte ans Statement uebergeben jetzt anschliessend unsere Daten. Da dies jetzt aber einen separaten Schritt darstellt, kann auch nichts mehr missverstanden werden - sowohl blah als auch O'Connor koennen wir jetzt direkt und unbehandelt uebergeben, weil wir dies jetzt nicht mehr in einem Kontext tun, in dem das Zeichen ' eine Sonderbedeutung haette. Wir uebergeben ja nur noch reine Daten, diese muessen nicht mehr geparst und dabei von Befehlswoertern getrennt werden.

MfG ChrisB