Interbase: Merkwürdiges Verhalten bei LEFT OUTER JOIN

[Uwe Raabe]

Ich denke auch, das ist interpretationsfähig. Eine klare Vorgabe das irgendwie umzusetzen kann ich auch nirgendwo finden.

[Delphi.Narium]

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

SQL-Code:

create table test (id int);

insert into test (id) values (1);

create view v1_1 as select * from test t1 where t1.id = 1;
create view v1_0 as select * from test t1 where t1.id = 0;
create view v1_1_0 as select * from test t1 where t1.id = 1 or t1.id = 0;

select t1.id as id1, t2.id as id2, t3.id as id3 from
  v1_1 t1 -- mit der Beispieltabelle eigentlich eher sinnfrei
  left outer join test t2 on t2.id = t1.id
  left outer join test t3 on t3.id = t1.id; -- steht alles schon im ersten left ...

select t1.id as id1, t2.id as id2, t3.id as id3 from
  v1_0 t1 -- mit der Beispieltabelle eigentlich eher sinnfrei
  left outer join test t2 on t2.id = t1.id
  left outer join test t3 on t3.id = t1.id; -- steht alles schon im ersten left ...

select t1.id as id1, t2.id as id2, t3.id as id3 from
  v1_1_0 t1 -- mit der Beispieltabelle eigentlich eher sinnfrei
  left outer join test t2 on t2.id = t1.id
  left outer join test t3 on t3.id = t1.id; -- steht alles schon im ersten left ...

-- hier müsste man mit 'nem "drumgelegten" select ggfls. noch Sätze mit gleicher id1 zusammenfassen
-- sum, max ... und group by id1
select t1.id as id1, t2.id as id2, null as id3 from
  v1_1 t1
  left outer join test t2 on t2.id = t1.id
union
select t1.id as id1, null as id2, t3.id as id3 from
  v1_0 t1
  left outer join test t3 on t3.id = t1.id;

oder

oder

oder

...

Das Beispiel ist zwar geeignet um festzustellen, dass x und y zum gleichen Ergebnis kommen, während z was anders behauptet, aber es ist nicht geeignet um zu verifizieren ob überhaupt eines der Ergebnis der umzusetzenden Aufgabenstellung entspricht, geschweige denn nach sinnvollen und verifizierbaren Alternativen zu suchen.

Bitte einfach mal die Aufgabenstellung verbal beschreiben, dann können wir weitersehen, welche Lösungsmöglichkeiten existieren.

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