Grundsatzdiskussion bind ./. fetch_assoc und prepare ./. mysqli_real_escape_string

[Regina Schaukrug]

data binding …/… "klassische" Fetch-Technik

wenn ich nach einer ehrlichen Antwort gefragt würde, was ich vom "data binding" halte, dann wäre meine Antwort ganz klar "Regelmäßig gar nichts!"

$result -> fetch_assoc() liefert alles, was benötigt wird. Wer unbedingt meint, dass er die Elemente seines Arrays anders benennen muss als die Spalten der Datenbank, der denkt aus meiner Sicht schon an dem Punkt etwas sehr falsches. Auch das Binden von Nicht-Arrays als Variablen ist aus meiner Sicht unnötig und sozusagen "semantisch falsch", weil mir als Progger dann der Sinnzusammenhang zwischen der Zeile einer Tabelle und den Daten in der Variable verloren geht.

Selbst wenn ich beim Planen was falsch gemacht habe, dann kann ich andere Spaltennamen im SQL bestimmen (SELECT foo AS bar)

$result -> fetch_row() hat aus meiner Sicht nur dann eine Berechtigung, wenn ich nur einen Wert erwarte - oder aber die Anzahl der Werte in einer Zeile nicht vorher bekannt ist (Man denke an das regelmäßig falsche SELECT * FROM ...) und ich den Spalten-Name nicht brauche. Aber selbst dann braucht man das binden nicht, im letzten Fall funktionierts nicht mal.

aber erst:

SELECT foo, bar from …

dann

$stmt -> bind_result ( $foo, $bar );

dann

while ( $stmt -> fetch () ) {
    $tabelle[] = array( 
                        'foo' => $foo,
                        'bar' => $bar
                      );
}

ist aus meiner Sicht eine enorme Verschwendung geistiger Leistung und Fingergelenkhaltbarkeit weil:

  $tabelle = array();
	if ( $result = $mysqli -> query( $query ) ) {
      while ( $row = $result -> fetch_row()) {
          $tabelle[] = $row;
      }
  } else { # Fehlerbehandlung

es mit ganz wenig Aufwand tut und keine besondere geistige Leistung erfordert.

Die Diskussion prepare vs query hatten wir schon öfter; query ist kompakter, dafür kannst Du Dir in den Fuß schießen wenn Du die Parameter unsauber ins Statement einbaust (Kontextwechsel-Problem).

Naja. Das Kontext-Wechsel-Problem kann man eigentlich ausschließen wenn man wie hier das Datum und die Empfängerliste vorher selbst zusammenbaut und also ausschließen kann, dass vergiftetes Zeug in den Parametern vorkommt. Selbst wenn man das nicht ausschließen kann dann gibt es das funktionierende mysqli_real_escape_string(). Das prepare lohnt eigentlich nur, wenn ich eine, bis auf die Parameter identische SQL-Abfrage mehrfach stelle, also nach dem $stmt -> prepare(…) mehrfach mit neuen Parametern versehe und jeweils abschicke.

Es könnte hier zwar sehr gut eine solche mehrfach gestellte Abfrage geben, nur wird das durch die Funktion gerade nicht so realisiert. Dazu wäre hier ein Objekt optimal gewesen in dem $stmt isoliert ist und erhalten bleibt. (Es gänge funktional auch wenn man alle Abfragen nacheinander stellt und die Ergebnisse "per Day" in einen Array ablegt und sich dann, beim Zusammenbau des Tags, wieder herauszieht.

Aber selbst dann könnte man sich das Stellen einer mehrfachen Abfrage schenken, weil Jahr, Tag und Monat sich auch gut in die Antwort aufnehmen lassen...