Was sind parametrisierte SQL-Statements und wann anwenden?

[juergen]

Hallo zusammen,

immer wieder liest man hier etwas von "parametrisierten SQL-Statements" anwenden...
Z.B. auch heute:

Zitat von Uwe Raabe:

Zitat von DeddyH:

Verwendest Du keine parametrisierten SQL-Statements?

<Sarcasm>So'n neumodisches Zeugs braucht doch eh niemand!</Sarcasm>

Dazu habe ich folgende Fragen:
1. Wann sollte man das anwenden?
2. Wie wendet man das an?
3. Was ist der Vorteil gegenüber einem normalen adden des SQL-Statements?

Ich würde mich über Antworten freuen welche ein Anfänger versteht. Ich will erst mal das "Grobe" verstehen, dann hoffe ich komme ich damit weiter.

Vielen Dank schon mal im Voraus!

[mkinzler]

Zitat:

1. Wann sollte man das anwenden?

Ich verwende eigentlich so gut wie immer parametrsierte Abfragen.

Zitat:

2. Wie wendet man das an?

Anstatt der Werte trägt man Parameter (Variablen) ein. Die Abfrage wird dann vom SQL-Server geparst (vorbereitet). Bei der eigentlichen Abfrage werden dann nur noch die Werte-Tupel übertragen.

Zitat:

3. Was ist der Vorteil gegenüber einem normalen adden des SQL-Statements?

-System sorgt für richtiges Format
-kein Quoten o.ä. nötig
-sicherer gegenüber sql injection
-bei mehrfacher Ausführung muss die Abfarge nur einmal "kompilliert" werden (Parsse, Zurgriffsplan erstellen usw.)-> bessere Performance

[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.

[himitsu]

1: fast immer
2: kommt auf die Zugriffskomponenten drauf an, aber oftmals gibt es neben den FieldByName-Methoden auch die passenden ParamByName usw.
3: Sicherheit, Einfachheit, Sicherheit, Fehlerunanfälliger, Sicherheit, ...

Erstmal muß man die Strings nicht umständlich "quoten" und wenn man das nicht machen würde, dann ist man lebensmüde.

PS: Gerade das ist eines der Hauptgründe, warum sich jemand in irgendeine Webseite reinhacken konnte.
- Eingaben nicht oder nicht ausreichend geprüft
- Daten ungeschützt in SQLs eingebaut => Code-Injection

Stell es dir wie den Format-Befehl vor:
- Im SQL-String gibt es Platzhalter, welche dann mit den eigentlichen Werten gefüllt werden, wobei hierbei die Datenbank/Zugriffskomponenten quasi aber die zugewiesenen Werte prüfen.
- Außerdem kann es schneller werden, da der SQL-Parser das SQL nur einmal pürfen/auswerten muß und man dann ganz schnell viele Werte/Datensätze verarbeiten kann, indem man nur noch die Parameterwerte anpasst.

[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;

[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

[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.