Dynamisches SQL - pro und contra

[exzel]

Hallo zusammen,

ich kenne mich mit dem Thema überhaupt nicht aus. Welche Vor- und Nachteile haben dynamische SQL-Queries?


Gruß und Dank!

 

[akretschmer]

Hallo zusammen,

ich kenne mich mit dem Thema überhaupt nicht aus. Welche Vor- und Nachteile haben dynamische SQL-Queries?


Gruß und Dank!

Was willst denn machen? Dynamisches SQL verwendet man z.B. zum Insert in partitionierten Tabellen (via TRIGGER).

 

[ukulele]

Oder wenn Teile des Querys aus einer Tabelle kommen, z.B. Spaltennamen.

 

[akretschmer]

Oder wenn Teile des Querys aus einer Tabelle kommen, z.B. Spaltennamen.

Das hab ich so extra vermieden zu sagen ...

 

[exzel]

Ich habe keinen konkreten Anwendungsfall. Derzeit arbeite ich mit statischen Queries.

Aber gehen wir von folgendem Beispiel aus. In einer Datenbank mit ca. 20 Tabellen werden Änderungen durchgeführt. Es wird in jede Datenbank eine zusätzliche Spalte hinterlegt, eine andere herausgelöscht. Jetzt müssten statische Queries erst entsprechend abgeändert werden, damit die Datenbank wieder korrekt angesprochen werden kann.

Ist die Anpassung der Queries in diesem Fall bei dynamischen Queries ebenfalls notwendig?

Gruß

 

[Hony%]

Oder wenn Teile des Querys aus einer Tabelle kommen, z.B. Spaltennamen.

Wird dadurch nicht das relationale Paradigma verletzt? Welche Vorteile sollen sich daraus ergeben? Und wird dadurch nicht die Wartbarkeit/Erweiterbarkeit behindert? Und wird nebenbei nicht auch noch der Optimizer ausgehebelt?

 

[akretschmer]

Aber gehen wir von folgendem Beispiel aus. In einer Datenbank mit ca. 20 Tabellen werden Änderungen durchgeführt. Es wird in jede Datenbank eine zusätzliche Spalte hinterlegt, eine andere herausgelöscht. Jetzt müssten statische Queries erst entsprechend abgeändert werden, damit die Datenbank wieder korrekt angesprochen werden kann.

Ist die Anpassung der Queries in diesem Fall bei dynamischen Queries ebenfalls notwendig?

Gruß

In dem Fall, also z.B. für solche Wartungsaufgaben, ist das doch eher nicht die Frage von Vor- oder Nachteilen, sondern der einfachen Machbarkeit. Da spricht nix dagegen, sich z.B. aus den Katalogtabellen die Tabellennamen zu klaubeln und da dynamisch draus die nötigen DDL-Kommandos zu bauen & abzufeuern.

Etwas anders ist das von @ukulele gemeinte: sich dynamisch aus einer Abfrage z.B. den Spaltennamen für die nächste Abfrage zu generieren ist auch dynamisches SQL, hat aber hier den massiv faden Beigeschmack, daß da was im Design grundlegend falsch läuft.
Daher auch mein Kommentar dazu und der von @Hony%

Es gibt weitere Anwendungsfälle: wenn man z.B. grad eben den Planner zwingen will, bisherige Ausführungspläne zu invalidieren. Aber das sind alles Fälle, wo man schon recht genau wissen sollte, was man tut.

 

[exzel]

Danke für die Antwort!

Wie steht es um die Sicherheit? Sind dynamische Queries leichter zu hacken als statische?

Gruß

 

[akretschmer]

Sind dynamische Queries leichter zu hacken als statische?

Gruß

Nein. Und auch nicht schwerer. Mach Dich schlau, wie SQL-Injection funktioniert.

 

[Hony%]

Wie steht es um die Sicherheit? Sind dynamische Queries leichter zu hacken als statische?

Eine "dynamische" Abfrage als parametrisierte Stored Procedure oder Prepared Statement dürfte nur sehr schwer durch SQL-Injections missbraucht werden.

 

[ukulele]

Ich glaube nicht das prepared Statements dynamische Abfragen ausführen können. Nur anders herum.

Bisher hatte ich zwei recht konkrete und intensive Anwendungsfälle.
1) Habe ich mir privat ein TSQL Script gebastelt das Dateinamen einließt und zu jeder Datei mit entsprechender Endung ein externes Komandozeilentool aufruft welches Detailinformationen zurück liefert.
2) Habe ich, um mir einen generellen Überblick über Datenbanktabellen zu verschaffen ein Script gebaut welches mir zu jeder Spalte einer DB ein paar Abfragen ausführt (kleinster Wert, größter Wert, Durschnitt, Anzahl NULL, etc.) und die Informationen alle in eine Tabelle legt, auch in TSQL. Ich gebe zu es ist nicht sehr komfortabel, aber es liefert eine Liste mit Tabellenname, Spaltenname und Eigenschaften.

 

[akretschmer]

Ich glaube nicht das prepared Statements dynamische Abfragen ausführen können.

Oach, mit genügend krimineller Energie, ähm, Phantasie, geht vieles:

test=*# select * from foo;
 i
---
 1
(1 row)

test=*#
test=*#
test=*# create or replace function f_foo(text) returns int as $$declare r int; begin execute 'select i from foo where ' || $1 || ' = 1' into r; return r; end; $$language plpgsql;
CREATE FUNCTION
test=*# prepare p_foo (text) as select * from f_foo($1);
PREPARE
test=*# execute p_foo('i');
 f_foo
-------
  1
(1 row)

test=*# execute p_foo('a');
ERROR:  column "a" does not exist at character 25
QUERY:  select i from foo where a = 1
CONTEXT:  PL/pgSQL function f_foo(text) line 1 at EXECUTE statement
STATEMENT:  execute p_foo('a');
ERROR:  column "a" does not exist
LINE 1: select i from foo where a = 1
  ^
QUERY:  select i from foo where a = 1
CONTEXT:  PL/pgSQL function f_foo(text) line 1 at EXECUTE statement

Bitte nicht nach dem Sinn fragen - der muß noch gefunden werden.

 

[Hony%]

Ich glaube nicht das prepared Statements dynamische Abfragen ausführen können. Nur anders herum.

Das kommt auch darauf an was man unter dynamisch versteht. Daher auch meine Gänsefüßchen. Reicht die Parametrisierung schon aus? Dann sind sie immer dynamisch. Muss der gesamte String individuell aufgebaut werden? Dann eher nicht.

 

[exzel]

Danke für die Antworten!