PDO - Beitrag

[erc]

Richtig. Aber die Werte werden je Datentyp anders behandelt. also warum will ich alle Werte als String verarbeiten lassen, wenn es vielleicht keine sind.

Warum sich darüber ein Kopf machen? Letztendlich spielt der Datentyp nur bei der Übermittlung zwischen Client und Server eine Rolle. Die Datenbank konvertiert diese Daten so oder so in das benötigte Format.(Wertebreich, Vorzeichen, Zeichensatz, Datum, Time usw...) Ausserdem sind die drei Parameter die dir PDO anbietet auch weit entfernt von dem was Mysql untersützt bei Prepared Statments. Das ist was die C API anbietet:

MYSQL_TYPE_TINY
MYSQL_TYPE_SHORT
MYSQL_TYPE_LONG
MYSQL_TYPE_LONGLONG
MYSQL_TYPE_FLOAT
MYSQL_TYPE_DOUBLE
MYSQL_TYPE_TIME
MYSQL_TYPE_DATE
MYSQL_TYPE_DATETIME
MYSQL_TYPE_TIMESTAMP
MYSQL_TYPE_STRING
MYSQL_TYPE_BLOB
MYSQL_TYPE_NULL

Und selbst das sind nicht alle Datentypen die Mysql kennt. Das ist meiner Meinung nach vergebene Mühe. Du sparst eine Handvoll Byte weil eine Ganzahl als Integer übertragen wird und nicht als Zeichenkette? *Schnarch*

[tr0y]

Laut Changelog wurde das verhalten von ATTR_EMULATE_PREPARES bis heute nicht verändert.

[dingsda]

Du meinst als Erwähnung? Von einer "fixen" Aufanahme in die $options hat mich das hier von jspit únd ChristianK abgehalten:

http://www.php.de/forum/webentwicklu...68#post1265168

meines wissens ist es allerdings so, dass EMULATE_PREPARES eben nicht per default auf false steht sonder leider auf true.
https://bugs.php.net/bug.php?id=54638
für die neueste Versionen von PHP könnte es vielleicht umgestellt worden sein hab aber dazu nichts gefunden und grad kein php installiert

[Arne Drews]

Bei Prepared Statements werden die Query und Parameter getrennt an die Datenbank übergeben, nothing new here I guess.

Richtig. Aber die Werte werden je Datentyp anders behandelt. also warum will ich alle Werte als String verarbeiten lassen, wenn es vielleicht keine sind.
Daher bleibe ich lieber bei bindParam für jeden Value. Für das Argument, was gleich kommen wird: "Was machst Du, wenn Du viele Values hast?!", dafür würde ich dann einen Wrapper schreiben, der das binden mit den korrekten Datentypen übernimmt.

[hausl]

Wobei, laut Doku:

PDO::ATTR_EMULATE_PREPARES Enables or disables emulation of prepared statements. Some drivers do not support native prepared statements or have limited support for them. Use this setting to force PDO to either always emulate prepared statements (if TRUE), or to try to use native prepared statements (if FALSE). It will always fall back to emulating the prepared statement if the driver cannot successfully prepare the current query.

[VPh]

Ah, ich wusste nicht, dass false als default gesetzt ist. Dann ist es wirklich nicht ganz so wichtig.
Eine Erwähnung sollte es Wert sein, jupp.
Ich kann auch heute Abend nochmal gucken, ich hatte da mal ein paar interessante Artikel, ob ich dir einen kleinen Text dazu schicken kann.

[hausl]

Was mir in dem Artikel noch fehlt ist PDO::ATTR_EMULATE_PREPARES
-> Native/Emulierte PS.

Du meinst als Erwähnung? Von einer "fixen" Aufanahme in die $options hat mich das hier von jspit únd ChristianK abgehalten:

http://www.php.de/forum/webentwicklu...68#post1265168

[VPh]

Moin,

Dann eine Frage für mich zum Verständnis:
Die PreparedStatements funnktionieren bei PDO meiner Meinung nach so gut, weil ich über bspw. bindParam() den Datentyp angeben kann.
Das ist mir bei der Verwendung von execute( $array ) nicht möglich. Daher habe ich das eigentlich bisher nie verwendet.
Wie zuverlässig erkennt er denn, welchen Datentyp ich übergebe?

Bei Prepared Statements werden die Query und Parameter getrennt an die Datenbank übergeben, nothing new here I guess.
Die Datenbank nimmt sich also die Query und wandelt die SQL-Syntax in c++ um, aus den verschiedenen Klauseln werden Objekt-Bäume gebaut, für die Parameter werden auch Objekte gesetzt.
Beim Execute() werden den Parameter-Objekten dann die Werte übergeben, zum Ausführen des Vergleichs wird dann der Wert des Objekts abgefragt.

Mein Fazit:
Prepared Statements sind sicher, weil die Werte nicht in die Query reingesetzt werden, sondern erst dazu stoßen wenn die Query schon auseinander genommen wurde und den SQL-Kontext verlassen hat.


Was mir in dem Artikel noch fehlt ist PDO::ATTR_EMULATE_PREPARES
-> Native/Emulierte PS.

[Arne Drews]

Ok, also alles als String. Dann bleibt die Variante für mich nur zweite Wahl

[hausl]

Arne, danke zuerst mal. Dann im Detail:

1. Das mit dem Beispiel geht klar, hatte vor das noch zu trennen (zwei Code-Blöcke), dann mach ich den Aufruf noch mit rein bzw. zeige bei der Klasse die Übernahme als privates property

2. Das "Mulit-Execute" (blöder Name, fiel kein besserer ein ) Ich habe es daher reingenommen, weil es neben dem escaping ja einer der beiden Vorteile von P.S. ist bzw. als solches verkauft wird. Aber gefallen tuts mir auch nicht wirlich, mir fiel nur echt kein wirklich gutes Beispiel ein für ein konkretes ANwendungsszenario. Ev. hab ich mir damit bereits schon selbst die Antwort gegeben - sind vermutlich eher speziele Einzelfälle und dann findet man es auch in der Doku. Passt ,ich gebs raus.

3. Array-Übergabe. Ich habe aus diesem Grund (Parameter nicht festmachbar) es zuerst nicht aufgenommen, aber finde es sieht von der Anwendung ganz parktisch muss ich sagen. Fachlich kann ich dir das leider nicht beantworten, müsste man mal bisschen Doku, google oder austesten. Irgend eine Regel/Logik muss es ja dafür geben.

Ah, hier: http://php.net/manual/de/pdostatemen...ute-parameters
Das nehme ich noch als Zitat mit auf!

input_parameters An array of values with as many elements as there are bound parameters in the SQL statement being executed. All values are treated as PDO::PARAM_STR.