Dual Archives - DBConcepts

For the English Version of this post >> click here

Wann immer ein simpler Wert per SQL gesetzt oder abgefragt werden soll, wird die Pseudotabelle DUAL dafür herangezogen.

Einer der populärsten Einsatzzwecke dafür war bis Oracle Version 10 die Nutzung von Sequences in PL/SQL.
Sequences mussten in diesen Oracle Versionen immer über eine SQL-Query abgefragt werden, der folgende Code funktionierte:

select my_seq.nextval from dual;

Der folgende Code funktionierte allerdings nicht:

v_myvar := my_seq.nextval;

Die DUAL Tabelle ist eine tatsächlich existierende physische Tabelle in der Datenbank welche im SYS-Schema liegt.

Sie verfügt über eine Spalte mit der Bezeichnung „DUMMY“ welche den Datentyp VARCHAR2(1) hat.
Die Zeile hat eine Zeile mit dem Wert ‚X‘, das kann mit folgendem Statment abgefragt werden:

select * from dual;

Theoretisch kann diese Tabelle auch verändert werden.
Natürlich rät Oracle streng davon ab das zu tun da eine Fülle an unvorhersehbaren Fehlern entstehen kann und wird.

Das grundlegende Verhalten könnte auch mit einer eigenen 1-Spalten-1-Zeilen-Tabelle simuliert werden, doch der Oracle Optimizer erkennt DUAL auch als Keyword und verfährt beim Execution Plan dann entsprechend.

Wie läuft das nun in Postgres?

Wenn Sie Code von Oracle auf Postgres portieren dann werden sie feststellen, dass das Statement von oben …

select 1 from dual;

…nicht funktioniert!
Postgres kennt keine DUAL Tabelle.

Nun gibt es zwei Möglichkeiten, je nachdem was die Ausgangslage und das Ziel ist:

Man legt die DUAL Tabelle in Postgres als „Dummy“-View an
Man passt das Statement an

Die erste Variante ist simpel und vor allem bei größeren Portierungen empfohlen, wo mehrere dutzend oder sogar hunderte Statements angepasst werden müssten.

Die zweite Variante ist bei wenigen Statements zu empfehlen, da sie dem Postgres Standard entspricht. Das entsprechende Statement in Postgres würde dann wie folgt aussehen:

select 1

Die komplette FROM-Klausel verschwindet hier!

Postgres macht durch diese Syntax die Verwendung einer Dummy-Tabelle unnötig um einen einzelnen Wert per SQL zu setzen oder abzufragen (z.B. auch das SYSDATE).

Das ist deutlich simpler.