ich sehe leider in verschiedenen Projekten Unmengen an String-Operationen, die immer wieder in Schleifen dasselbe
SQL-Statement zusammen basteln, um die Parameter zu setzen.
Da gehen Statements bis in den Kilobyte-Bereich und keiner sieht mehr durch.
Es ist dort sinnvoller (aus Performance-Sicht und der Übersichtlichkeit wegen) ein
SQL-Statement einmalig zu "basteln" (z.B. in einem
Query-Tool) und die dann vielleicht 20 Parameter zu setzen. Das ganze Gedönse der unterschiedlichen Behandlung von Datums-Formaten (z.B.) entfällt auch.
eine Anmerkung noch zu mkinzlers Beispiel: ich würde nicht unbedingt auf Value gehen, sondern direkt mit AsString, AsDate usw arbeiten, damit der zu erwartende Datentyp auchschon im Code klar ist:
Delphi-Quellcode:
Query.ParamByName('
vorname').AsString := '
Hans';
Query.Params[1].AsString := '
Mueller';
Query.ParamByName('
gebdat').AsDate := ...;
Query.ExecuteSQL;
Dann hat man u.U. aber viele unnötigen Cast-Operationen.
Vielleicht sollte man beim Thema Parameter und Performance 2 Dinge unterscheiden.
Anwendungsperformance (beim Client) und Abfrageperformance (auf der
DB).
Bei "einmaligen" Abfragen geht es in erster Linie um die Anwortzeit der
DB und die ist weder von der clientseitigen Aufbereitung noch von der Parametrierung abhängig. Genauer, parametriert, typisiert, egal. Die Analyse dürfte vom Laufzeitverhalten nur einen Bruchteil ausmachen, gegenüber dem Aufbau des Datencursors.
Bei "massenhaften" Abfragen sieht es anders aus. Sowohl die Parametrierung im Client (Parameteransprache via Index/Name, ggF. Casts, ..) also auch die Analyse
DB seitig werden zum Laufzeitfaktor. "Massenhaft" kann dabei sowohl ein Client auftreten mit einer
Query Loop, als auch viele Clients (100, 1000) mit der immer gleichen Gelegenheits-Abfrage.