Was sind parametrisierte SQL-Statements und wann anwenden?

[juergen]

@mkinzler,

schon mal Danke!

Den Punkt 2 verstehe ich noch nicht wie ich das umsetzen muss.
Angenommen ich habe eine Query. Die hat die Eigenschaft "Params".
Muss ich dort anstelle in "SQL" das Statement hinterlegen?

Wie müsste dann folgender Aufruf implementiert werden?

Code:

'select A.Name, A.Kd-Nr from Adressstamm as A'

//Edit: wobei A.Name = string und A.Kd-Nr = Integer

[Union]

Parameter kann man natürlich nur setzen, wo auch welche sinnvoll sind. Deine Beispielabfrage lät sich nicht parametrisieren. Ein Beispiel wäre:

Code:

select A.Name, A.Kd-Nr from Adressstamm as A
where A.Kd-nr = :Kdnr

Den Parameter der Query füllst Du dann z.B. so und führst die Abfrage durch:

Delphi-Quellcode:

Query.Active := False;
Query.ParamByName('Kdnr') := '12345';
Query.Active := True;

Sinnvoll ist das besonders, wenn die selbe Abfrage in einer Schleife mehrfach ausgeführt werden soll. Je nach Intelligenz des Servers wird dann beim ersten Mal wie bereits von den anderern beschrieben, die Query vorbereitet und in den Folgeaufrufen nur noch der Parameterwert gesetzt.

[mkinzler]

Das ist ein schlechtes Beispiel, da hier nichts parammetrisierbar ist

SQL-Code:

select 
    A.Name, 
    A.Kd-Nr 
from 
    Adressstamm
where
  A.Kd-Nr = :kdnr;

Der Parameter kdnr ist durch den Doppelpunkt erkennbar

Anderes Beispiel

SQL-Code:

insert into person ( vorname, name, gebdat, ...)
values ( :vorname, :name, :gebdat, ...)  ;

Delphi-Quellcode:

Deklaration Abfrage und deren Vorbereitung:
Query.SQL.Text := <Abfrage>;
Query.PrepareSQL;
....

Ausführung der Abfrage (mehrmals möglich):

Delphi-Quellcode:

Query.ParamByName('vorname').Value := 'Hans';
Query.Params[1].Value := 'Mueller';
Query.ParamByName('gebdat').Value := ...;    
Query.ExecuteSQL;
Query.ParamByName('vorname').Value := 'Susi';
Query.Params[1].Value := 'Mueller';
Query.ExecuteSQL;

Hans und Susi sind Zwillinge, der Nachname und das Geburtsdatum ist gleich.
Dem Parameter kannst Du direkt ein Datum zuweisen und musst Dir keine Gedanken um das Datumsformat machen.

[juergen]

Ahhhh, supi, es lichtet sich so langsam. Danke an Alle!
Es geht doch nichts über anschauliche Beispiele. Dann werde ich das in Zukunft mit den Parameter-Übergaben so umsetzen.

Allen eine Gute N8!

[joachimd]

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;

[mkinzler]

Zitat von joachimd:

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.

[Dejan Vu]

Zitat von mkinzler:

Zitat von joachimd:

.. sondern direkt mit AsString, AsDate usw arbeiten, damit der zu erwartende Datentyp auch schon im Code klar ist

Dann hat man u.U. aber viele unnötigen Cast-Operationen.

Den Einwand verstehe ich nicht. Man hat gerade keine Cast-Operationen, und damit auch keine Unnötigen.

Delphi-Quellcode:

myQuery.ParamByName('Foo').Value := a;
myQuery.ParamByName('Bar').Value := b;
// vs
myQuery.ParamByName('Foo').AsString := a;
myQuery.ParamByName('Bar').AsDateTime := b;

Bezüglich der Feldnamen/Tabellen als Parameter: Wenn ich mir meine WHERE-Klausel dynamisch zusammenbauen will, wäre das vielleicht ganz praktisch, aber da muss man eben direkt an die Query ran. So wild ist das ja nun auch nicht.

[TRomano]

Zitat:

von Dejan Vu
myQuery.ParamByName('Foo').Value := a;
myQuery.ParamByName('Bar').Value := b;
// vs
myQuery.ParamByName('Foo').AsString := a;
myQuery.ParamByName('Bar').AsDateTime := b;

In deinem Beispiel beschreibst Du genau das Problem: Deinen Feldnamen sind 'Foo' und 'Bar' und woher soll man wissen, was wirklich hinter den Feldnamen an Typen steckt. Sollte mal ein anderer Entwickler an deinen Source ran ... viel Glück !
Im zweiten Teil ist es klarer und verständlicher ...

[TRomano]

Hallo zusammen,

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.

Gruß Thomas

[jobo]

Zitat von TRomano:

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.

Zitat von mkinzler:

Zitat von joachimd:

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.