Was sind parametrisierte SQL-Statements und wann anwenden?

[Der schöne Günther]

Ich habe mich bis heute immer das gleiche gefragt, jetzt weiß ich endlich auch mit Sicherheit, was Parameter bei Queries sind

Kann jemand noch ein bisschen aus der Praxis von konkreten Datenbanken erzählen? Ich könnte mir jetzt vorstellen, dass ein DMBS es beispielsweise erlauben würde, den Tabellennamen selbst zu paramatrisieren, ein anderes hingegen nicht. Gibt es da was?

[DeddyH]

Nach meiner Kenntnis kann man grundsätzlich ausschließlich Werte parametrisieren, also weder Datenbank-, Tabellen- noch Feldnamen.

[himitsu]

Also, Parameter sind grundsätzlich erstmal nur Werte.
Namen von Tabellen und Feldern sind aber keine Werte.

Dafür gibt es dann z.B. Makros, bei einigen Komponenten, wie z.B. den xxDAC's.

Delphi-Quellcode:

Query.SQL.Text := 'SELECT AnderesFeld FROM &Table WHERE Feld = :Wert';
Query.MacroByName('Tabelle').Value := 'irgendwas';
Query.ParamByName('Wert').AsString := 'abc';
Query.Open;
ShowMessage(Query.FieldByName('AnderesFeld').AsString);

[jobo]

Zitat von Der schöne Günther:

Kann jemand noch ein bisschen aus der Praxis von konkreten Datenbanken erzählen? Ich könnte mir jetzt vorstellen, dass ein DMBS es beispielsweise erlauben würde, den Tabellennamen selbst zu paramatrisieren, ein anderes hingegen nicht. Gibt es da was?

Ich kann zu Oracle konkret sagen, die Analyse der Abfrage erfolgt ganz stumpf nach Gleichheit. Ist die Abfrage nicht exakt identisch (select * from customer where nr = 1/select * from customer where nr = 2), sind es zwei verschiedene Abfragen und es werden beide analysiert.
Bei Parametern die dann als Platzhalter im Querytext konstant bleiben, erfolgt die Analyse nur bei der ersten Abfrage.

Dynamische Tabellennamen
Wäre manchmal schön, aber
Das riecht etwas nach verkorkstem Datenmodell ala "ich habe hier alle Kunden, die 2014 dazu gekommen sind in CUSTOMER2014 und dann in tabelle CUSTOMER2013 die von .. ".
Es bedeutet im Prinzip, dass ich gleiche Strukturen vorsehe und ein Merkmal aber im Tabellenname definiere und das ist meistens schlecht.
Es gibt bei Oracle eine API mit der man dynamisch SQL konstruierten kann, aber das ist wohl ein Thema für sich.

[Stevie]

Zitat von jobo:

Ich kann zu Oracle konkret sagen, die Analyse der Abfrage erfolgt ganz stumpf nach Gleichheit. Ist die Abfrage nicht exakt identisch (select * from customer where nr = 1/select * from customer where nr = 2), sind es zwei verschiedene Abfragen und es werden beide analysiert.
Bei Parametern die dann als Platzhalter im Querytext konstant bleiben, erfolgt die Analyse nur bei der ersten Abfrage.

Das ist auch beim SQL Server so. D.h. mit unparametrisierten Queries kann man den Prozedurcache so richtig derbst zumüllen.

[Union]

Zitat von Der schöne Günther:

Kann jemand noch ein bisschen aus der Praxis von konkreten Datenbanken erzählen? Ich könnte mir jetzt vorstellen, dass ein DMBS es beispielsweise erlauben würde, den Tabellennamen selbst zu paramatrisieren, ein anderes hingegen nicht. Gibt es da was?

Tabellennamen lassen sich normalerweise nur über Tricks parametrisieren. Und dann dient das auch nicht der Optimierung und die Implementierung ist datenbankabhängig:

Code:

declare @c cursor as 
select name, 
      case 
      when substring(name,2,1) between '0' and '9' then 1990 + cast(substring(name,2,1) as SQL_INTEGER)       
      else 2000 + Ascii(substring(name,2,1)) - 65
      end as Jahr
from rechnungen;
open @c;
try
   drop table #temp;     
catch all
end try;
create table #temp (Name char(8), Id integer);
while fetch @c do
  execute immediate 
    'insert into #temp (Name, Id, Umsatz) '+
   'select name, b.id'+
   'from rechnungen inner join '+
        -- Hier wird der Name der Tabelle aus zwei Feldern des erzeugten Cursors gebildet
        -- In der gejointen Tabelle steht das Feld Umsatz
   '(select top 1 * from ['+Trim(convert(@c.Jahr, SQL_CHAR))+'\'+Trim(@c.name)+']) B '+
   'on True '+
   'where rechnungen.name = '''[e-mail]+''';';
end while;
close @c;
-- Rückgabe-Datenmenge
select * from #temp;