@Delphi.Narium: Warum keine Temp-Table? (am Besten nur für diese Session)
Um es auf allen Systemen gleich zu haben und nicht bei der Portierung immer daran zu denken:
Hier hab' ich die Tabelle, dort ist es eine Temp-Tabelle, die ich mir ggfls. anlegen bzw. befüllen muss. Anderswo geht ein Select auch ohne Angabe eines Tabellennamens, ...
'ne Temp-Tabelle für eine Session muss ich dann pro Session entsprechend "versorgen". Pech, wenn ich dann "mal eben" von FireBird nach Oracle wechsel, dann muss ich den entsprechenden Quelltext "weglassen", brauche also ein (wenn auch nur marginal) andere Implementierung. Mag es halt, wenn ein Programm unverändert gegen jede x-beliebige Datenbank läuft. Sorge halt dafür, dass auf Datenbankseite eine möglichst große Übereinstimmung besteht, sodass ich mir im Programm keine Gedanken darüber machen muss, welcher Quelltextbereich, welche SQLs ... nun bei der Nutzung von Datenbank X zu nehmen sind, welche bei Datenbank Y und was muss ich morgen machen, wenn noch Datenbank Z unterstützt werden soll?
Mit der Einheitlichkeit der
SQL-Möglichkeiten zwischen den verschiedenen Datenbanken ist es ja nunmal nicht so weit her. (Wie man ja auch hier an den unterschiedlichen Lösungen sehen kann.)
Meine Lösung sieht halt so aus, dass ich für möglichst große Einheitlichkeit auf Datenbankseite sorge. Und da scheint mir das einmalige Anlegen und Befüllen der Tabelle Dual eben ein gangbarer Weg zu sein. (Und ja, es ist nur einer von vielen möglichen.)