Interbase: Merkwürdiges Verhalten bei LEFT OUTER JOIN

[jobo]

Ah, jetzt versteht man sogar wofür das Ganze.

Es ändert nichts an meiner Auffassung, ich würde solche Joins nicht machen. (Mit der Idee im Hirn, vielleicht jetzt schon, aber nein)
Interessant finde ich Deine Anmerkungen zur bevorzugten Lösung. Am Ende ist ja das, was Du wollen würdest und womit Du Dich abfinden musst doch relativ nah aneinander. Nicht was den Join angeht, aber die "Vorverarbeitung" zur Ausgabe des finalen Wertes.

Einmal entscheidet NULL über die Auswahl des ausgegebenen Wertes,
einmal ein separates Feld.

Auch wenn die Funktion (coalesce versus case) unterschiedlich ist, der Mechanismus ist nahezu gleich.
Die CASE Variante ist sogar aufschlussreicher für die Nachwelt (würde ich sagen).

[jobo]

Was mir noch eingefallen ist:
Vielleicht findest Du auf den Outer Tables (rechte Seite) Ersatzfelder für das Flag.
Annahme wäre, dass man nicht aus Spaß zwei unterschiedliche Tabellen referenziert, was sich am Ende auch in Struktur und Inhalte niederschlagen sollte.
Damit könntest Du dann den Vorschlag von Uwe verfolgen. Das typisierende Outerjoin Kriterium, das jetzt noch nach links zeigt, auf die "Muttertabelle", ersetzen durch einen "äquivalenten" TypIndikator in der Outertabelle rechts. Muss natürlich 100 Pro wasserdicht sein.
Dann hättest, was Du haben willst.

[Jumpy]

Ich verstehe bei der ganzen Konstruktion nicht, warum es nötig ist bei den Joins auf den Ref-Typ Bezug zu nehmen. Warum den Join einschränken?

SQL-Code:

select
  id, ref_typ, ref, 
  case when ref_typ=1 then test_1.data else test_2.data end as data
from test
  left outer join test_1 on ref1 = ref
  left outer join test_2 on ref2 = ref

Sollte doch je nachdem performanter sein als die vielen Subselects der Variante 3.

[HeZa]

Zitat von Jumpy:

Sollte doch je nachdem performanter sein als die vielen Subselects der Variante 3.

Genau so ist es. Deswegen hatte ich auch im Endeffekt so umgesetzt.