Interbase: Merkwürdiges Verhalten bei LEFT OUTER JOIN

[p80286]

Zitat von Delphi.Narium:

Irgendwie ist mir eigentlich garnicht klar, was genau gewünscht ist.

Einfach nur formale Spielerei?
Eine Tabelle mit einem Datensatz und zwei Aliassen(?) ist ja eher sinnfrei.

Und ich glaube was er erreichen wollte hat der TE erreicht. Diskussion

Zitat:

Danach bitte noch dem LEFT OUTER JOIN mitteilen, dass es auch ein LEFT OUTER JOIN ist.

??? was meinst Du damit? gibt es da noch irgendwelche Fehler?

Gruß
K-H

[jobo]

Ich bin mir nicht sicher, ob man die Fragen von Heimlich ernst nehmen muss.

Laut Eröffnungspost hat Uwe Raabe ja bereits ein adaptiertes Statement gezeigt, das die Daten liefert, die der TE erwartet. Die Sache könnte hier zuende sein.

Ob es nun mehr um Erwartungen geht oder mehr um Grundsatzfragen oder Fehleranalyse oder freudiges Tüfteln kann man derzeit nicht genau erkennen.

Ich könnte an der Stelle anführen, dass es sich um einen "Best Practice Fall", eine best practice Verletzung sozusagen. Die Verwendung von Left Outer Joins wird hier nicht im gedachten Sinne, also nicht ausgetestet, nicht wie gedacht eingesetzt.

[HeZa]

Hallo,

erst mal allen vielen Dank.

Ich hatte gehofft, dass es einen simplen Work Around gibt. Darum hatte ich den Hinweis zu Klammern auch gleich mal ausprobiert. Das ändert aber leider nicht das Ergebnis.

Das Beispiel was ich gezeigt habe war so reduziert, um die Problematik zu zeigen.

Warum ich so etwas verwenden wollte, hängt mit den Gegebenheiten des Datenbankdesigns zusammen. Ich erspare es mir jetzt Gründe aufzuzählen warum manchmal eine komplexe SQL-Abfrage einer Änderung des Datenbankdesigns vorgezogen wird.

Für die Interessierten folgt ein SQL-Script, das die Auslösende Problematik besser wieder gibt. Die Basis Tabelle hat ein Referenzfeld. Diese Referenz kann abhängig von einem Typ-Feld auf zwei verschieden Tabellen verweisen, deren Ids auch noch die gleichen Werte haben können.

Interessant dabei ist, dass das 2. SELECT von Interbase mit einer Fehlermeldung quitiert wird und nur das 3.SELECT zum von mir erwarteten Ergebnis führt.

Code:

create table test (id int, ref_typ int, ref int);
create table test_1 (ref1 int, data1 int);
create table test_2 (ref2 int, data2 int);
 
insert into test (id, ref_typ, ref) values (1, 1, 1);
insert into test (id, ref_typ, ref) values (2, 2, 1);
insert into test (id, ref_typ, ref) values (3, 1, null);
insert into test (id, ref_typ, ref) values (4, 2, null);
insert into test_1 (ref1, data1) values (1, 100);
insert into test_2 (ref2, data2) values (1, 200);
 
-- führt zum erwarteten Ergebniss in MySQL, Oracle, PostgreSQL, SQLite, MS-SQL
select
  id, ref_typ, ref, coalesce(data1, data2) as data
from
  test
  left outer join test_1 on ref1 = ref and ref_typ = 1
  left outer join test_2 on ref2 = ref and ref_typ = 2;
 
-- führt zum erwarteten Ergebniss in MySQL, Oracle, PostgreSQL, SQLite, MS-SQL
select
  id, ref_typ, ref,
  case
    when ref_typ = 1 then (select data1 from test_1 where ref1 = ref)
    when ref_typ = 2 then (select data2 from test_2 where ref2 = ref)
  end as data
from
  test;
 
-- führt zum erwarteten Ergebniss in MySQL, Oracle, PostgreSQL, SQLite, MS-SQL, Interbase
select
  t.id, t.ref_typ, t.ref,
  case
    when t.ref_typ = 1 then (select t1.data1 from test_1 t1 where t1.ref1 = t.ref)
    when t.ref_typ = 2 then (select t2.data2 from test_2 t2 where t2.ref2 = t.ref)
  end as data
from
  test t;
 
drop table test;
drop table test_1;
drop table test_2;

Ich verwende jetzt eine Variante des 3. SELECT. Finde ich nicht schön, funktioniert aber.

Ciao HeZa

[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.