nicht angemeldet
Hi!
Wenn Du über Geschwindigkeit reden willst, fang mit Benchmarks an, statt Funktionsaufrufe zu zählen.
Ich meinte nicht direkt die Performance, die hängt ja meist von der Query selbst und der dabei entstehenden Datenmenge ab. Mir ging es vorwiegend um den Schreibaufwand. Es sind ja nicht nur die Funktionen sondern auch das Drumherum, wie Fehlerbehandlung. Die Funktionsaufrufe wirken sich nur dann erwähnenswert auf die Performance aus, wenn man einen langsam angebundenen MySQL-Server ansprechen will oder muss. Da ist jeder Rounddtrip einer zu viel. Doch dieses Szenario trifft auch nur die wenigsten.
Erschwerend kommt hinzu, dass es nur vorgesehen ist, einzelne Variablen zu binden. Arrays gehen nur recht umständlich anzuflanschen.
Exakt das Problem hast Du auch, wenn Du Werte direkt ins SQL reinschreibst.
Mit vsprintf() und array_map('mysql_real_escape_string', $values) bekommt man das schnell gelöst, aber die Referenzgeschichte beim Binden verhindert solche einfachen Lösungen.
Muß ich beim DBI auch nicht:
Das nützt nur dem PHP-Anwender gar nichts. PDO hilft schon ein Stück weit, ist jedoch nicht in jedem Fall eine Lösung, weil er dann auf die auf MySQL zugeschnittenen Funktionen verzichten muss. Das fängt beim Einstellen der Verbindungskodierung an [*] und beinhaltet beispielsweise auch Multi-Querys.
[*] SET NAMES geht natürlich, doch davon bekommt der Escape-Mechanismus nichts mit, und ist dann für einige asiatische Kodierungen nicht mehr verwendbar.
Ich *KANN* natürlich auch binden,
Auch die Parameter für die Platzhalter kann man binden, per bind_param().
Wer möchte, kann auch per bind_param_array() Arrays als Parameter binden und entsprechend execute_array() aufrufen.
Und diese Wahlmöglichkeit hat man bei P.S. mit der mysqli-Extension nicht. Entweder P.S. mit Bindung an dedizierte Variablen vor _und_ nach dem Execute oder auf P.S. verzichten.
Damit ergibt sich auch immer ein zusätzlicher Roundtrip zum DBMS gegenüber der herkömmlichen Variante.
Woher soll der kommen?
Der Satz bezog sich auf das Prepare. Herkömmlich gibt es genau einen Roundtrip bei mysql(i)_query(). Bei P.S. hast du mit Prepare und Execute zwei Roundtrips.
Wenn Du für jeden Request die Script-Instanz von Null neu startest, hast Du natürlich recht, aber dann läuft PHP im CGI-Modus und der Aufwand für das Prepare dürfte gegenüber dem Start des PHP-Interpreters ziemlich zu vernachlässigen sein.
Ja (wenn man keinen langsam angebundenen MySQL_Server hat - beispielsweise einen, der aus organisatorischen Gründen am anderen Ende der Welt steht. Da hilft selbst eine schnelle Leitung nicht, die Laufzeit ist physikalisch bedingt. Aber der Fall trifft wohl für die meisten Wald-und-Wiesen-Anwender ebensowenig zu wie mod_php nutzen zu können.)
Ich kann sehr gut verstehen, wenn jemand dieses umständliche Handling der Prepared Statements in PHPs mysqli-Extension nicht mag.
Tja, schlechtes API-Design. Schon angefangen damit, dass ich viel Code anfassen muß, wenn ich mit einer anderen DB arbeiten will.
Auf ein anderes DBMS umsatteln zu müssen ist vermutlich auch ein selten in Frage kommendes Szenario für die P.S.-Nicht-Kenner.
Bei DBI ist das exakt eine Stelle, dort wo ich den DB-Treiber im connect()-Aufruf festlege.
Und dann kommen noch die Unterschiede der SQL-Dialekte hinzu. Man wechselt vermutlich eher selten, weil bei gleichen SQL-Statements ein anderes DBMS Vorteile verspricht. Die könnten dann höchstens auf administrativer oder finanzieller Seite liegen. Ich sehe eher Wechsel-Szenarien aufgrund von Features des anderen DBMS - und das erfordert doch etwas mehr Aufwand als den Connection-String anzupassen.
vorausgesetzt, der geneigte Coder hat nicht angefangen, abgedrehte DB-Spezialitäten in den Code einzubauen.
Da braucht man nicht auf "abgedrehte" Sachen zu schauen. Es fängt ja schon bei auto_increment vs. Sequenzen an und hört bei teilweise grundlegenden Funktionen noch lange nicht auf.
Lo!