Parameter & Prepared

[Dejan Vu]

War ja nur ne Idee. Mal sehen, woran es liegt.

[EgonHugeist]

Hmmm

Meine Frage wäre, ob FD tatsächlich die MySQL-Prepared-stmt API nutzt oder nicht:
http://dev.mysql.com/doc/refman/5.0/...-problems.html
Die API ist buggy seit v4.1!

Des weiteren bietet MySql keine API die Parameter und deren Eigenschaften "sicher" zu hinterfragen:
http://dev.mysql.com/doc/refman/5.0/...-metadata.html
Die Funktion existiert auch schon ewig und tut nix, rein gar gar nix!

Wir bei Zeos haben den Support drin, meine Benchmarks mit dem "real"-prepared Sch.. sind ehrlich gesagt ernüchternd ausgefallen, da bei Parameter-Typ oder Größen-Änderungen immer wieder neue bind+ReAllocMem(wenn der parameter mehr Speicher braucht) notwendig sind. Tatsächlich ist MySQL so 'ne kleine Ausnahme und wirklich Höllen schnell, was das Parsen der Strings und "escapen" angeht.

Der Weg rückwärts als fetch fällt da genauso schlimm aus. Die C-API bietet ResultSets ebenfalls an. Der Performance-Drop ist wirklich übel auch das Speicher handling für Lob's.
Hat jemand eine Ahnung in welcher Art MySQL seine Daten ablegt? String oder Binär (e.g. Ordinals, Floats etc.)?
Und weil wir schon dabei sind: PG bietet seit v8.0 auch ein binär Protokol, doch wie legt PG seine Daten ab? Könnte da was zu holen sein? Fürchte 'ne menge Zeit für die gleiche Pusteblume zu investieren...

Ist eigentlich 'ne dumme Frage, aber Zahlen Lügen halt nicht! Ich kanns mir nicht anders erklären.. Bei PG würde es mich nicht mal wundern, wenn die unendliches String-Parsing innerhalb der Tabellen betreiben.

By default nutzt Zeos die Emulierung der Parameter und bis heute ist diese schneller (wenn man alles drauf trimmt, mal vom Delphi-Unicode-Gedöhns abstand hält und ein paar schneller RTL-Replacements einbaut), und wie voran geführt: sicherer.

Michael

Ahh noch etwas, bevor ich korregiert werde (worauf Bernhard verweist) diese "Prepare xxxx" etc. Syntax hatte ich auch schon durch gespielt. Vielleicht habe ich mich da zu dumm angestellt, doch meine Messungen, aufgrund der vielen call's, fiehlen noch negativer aus...

Somit würde ich mich im Fall MySQL Mavarik anschließen und einfach mal alles in Frage stellen (wenn FD auch emuliert, natürlich und keine "strings" escaped werden müssen)!