Firebird: SQL JOIN gesucht

[MyRealName]

Ich habe 2 Tabellen, die aber eigentlich keinen gemeinsamen Nenner haben, mache ich da einen select drauf ohne einen direkten JOIN zu nutzen, also

Code:

select *
from Property_names P, Lieferadressen L
WHERE P.Id_Type=1

dann kommt genau raus, was ich will: Für jeden Eintrag in Property_Names finde ich x Einträge (wobei x = Anzahl der Einträge in Lieferadressen)

Jetzt lässt Firebird aber keine mixed-JOINS mehr zu und ich würde mich für explizite JOINs eintscheiden wollen.
Frage nun, wie geht das, wenn da keine Verbindungsfelder da sind ?

Weil das hier geht ja nicht:

Code:

SELECT L.*, P.*
FROM Lieferadressen L
JOIN Property_names P
WHERE P.Id_Type=1

Ideen?

[lxo]

Zitat:

Zitat von MyRealName (Beitrag 1528835)

Ich habe 2 Tabellen, die aber eigentlich keinen gemeinsamen Nenner haben, mache ich da einen select drauf ohne einen direkten JOIN zu nutzen, also

Code:

select *
from Property_names P, Lieferadressen L
WHERE P.Id_Type=1

dann kommt genau raus, was ich will: Für jeden Eintrag in Property_Names finde ich x Einträge (wobei x = Anzahl der Einträge in Lieferadressen)

Jetzt lässt Firebird aber keine mixed-JOINS mehr zu und ich würde mich für explizite JOINs eintscheiden wollen.
Frage nun, wie geht das, wenn da keine Verbindungsfelder da sind ?

Weil das hier geht ja nicht:

Code:

SELECT L.*, P.*
FROM Lieferadressen L
JOIN Property_names P
WHERE P.Id_Type=1

Ideen?

Hilft dir vielleicht "cross join" weiter?
siehe https://firebirdsql.org/file/documen...elect-joins-de

SQL-Code:

select *
from Property_names P
cross join Lieferadressen L
WHERE P.Id_Type=1

[joachimd]

Datenbankdesign oder Beschreibung kaputt.
Dein erstes Statement macht ein kartesisches Produkt - also alles mit allem verknüpfen.
Kannst Du evtl mal anhand von wenigen Beispieldaten zeigen, was es gibt und was Du erwartest?

[MyRealName]

Die Idee ist, dass man eine Property für etwas anlegt (sagen wir für einen Kunden). Jetzt kann der Kunde natürlich mehrere Lieferadressen haben. Ich möchte natürlich nciht für jeden Kunden und für jede Property das anlegen. Die Idee ist also, die Property in PROPERTY_NAMES abzulegen und das SQL lädt jede Property (wo ID_Type = x, wobei x jeweils für das genutzte Object steht, zum Bsp. Kunde oder Lieferant oder Produkt) in Verbindung zur Lieferadresse. Wenn nichts angelegt ist, muss halt ein leerer String kommen, aber die Lieferadresse muss zur Property da sein.

CROSS JOIN tut es. Hatte das gar nicht mehr auf dem Schirm, weil ich es nie brauchte. Danke!

[joachimd]

also eine n:m Beziehung ... die wird idR über eine Zwischentabelle abgebildet.

[IBExpert]

neben dem hinweis von joachim, das eine zwischentabelle dafür angesagt sein sollte, schau dir mal bei deinen sqls mit einem geeigneten werkzeug (ich wüsste da eins) an, wie viele indexed oder non indexed reads du damit erzeugst. wenn beide tabelle je 100 datensätze haben rödelt firebird ohne passende joins oder zwischentabelle 10000 recordkombinationen zusammen, aus denen du dann die ergebnismenge bekommst. Wenn in beiden tabellen je 1000 records sind, dann wird die eingangsmenge schon aus 1mio records bestehen.

Wofür auch immer du deine konstruktion benutzen willst, mach es anders, bevorzugt mit zwischentabelle und sei es auch nur das die nur aus 2 ids besteht, ist alles besser als es so zu machen.

[MyRealName]

Danke Holger, ich schau morgen mal nach einer Lösung mit einer Zwischentabelle. Und ein gutes Werkzeug haben wir schon, ist sogar das Beste :) IbExpert

[Jumpy]

Zitat:

Zitat von MyRealName (Beitrag 1528835)

dann kommt genau raus, was ich will: Für jeden Eintrag in Property_Names finde ich x Einträge (wobei x = Anzahl der Einträge in Lieferadressen)

Unabhängig davon, dass sinnvoll ist, was Joachim und IBExpert gesagt haben. Wäre das nicht mit einem Left Join (statt Cross) abhandelbar mit einer immer wahren Bedingung?

[Sinspin]

Nö. Nicht mit der aktuellen Umsetzung. Denn es gibt keine ordentliche Bedingung. Daher ja überhaupt erst die Frage.
Ich würde auch mit einer weiteren Tabelle arbeiten um die Beziehung abzubilden. Das macht es leicht sich daraus jeden Art von Information zu ziehen, egal in welche Richtung man schaut.

[Jumpy]

Zitat:

Zitat von Sinspin (Beitrag 1528881)

Nö. Nicht mit der aktuellen Umsetzung. Denn es gibt keine ordentliche Bedingung. Daher ja überhaupt erst die Frage.
Ich würde auch mit einer weiteren Tabelle arbeiten um die Beziehung abzubilden. Das macht es leicht sich daraus jeden Art von Information zu ziehen, egal in welche Richtung man schaut.

Ah OK, ich kenn mich halt mit Firebird nicht aus. In Oracle hätte man das glaub ich sinngemäß so machen können:

SQL-Code:

Select T1.*,T2.*
From T1
Left Join T2 On 1=1
Where T1.Feld1='Irgendwas'

[Delphi.Narium]

Zitat:

Zitat von Jumpy (Beitrag 1528882)

SQL-Code:

Select T1.*,T2.*
From T1
Left Join T2 On 1=1
Where T1.Feld1='Irgendwas'

Geht in Firebird auch.

[Sinspin]

Wenn man beide Tabellen bedingungslos zusammenführen will mag das eine Lösung sein.
Aber es geht ja schon um eine Beziehung zwischen beiden Tabellen. Nur das diese bisher nicht via Index Feld gelößt ist. Sondern ein Flag in einem Feld abgelegt ist dessen Wert festlegt welche Sätze aus der anderen Tabelle gebraucht werden.

[Jumpy]

Zitat:

Zitat von Sinspin (Beitrag 1528894)

Aber es geht ja schon um eine Beziehung zwischen beiden Tabellen. Nur das diese bisher nicht via Index Feld gelößt ist. Sondern ein Flag in einem Feld abgelegt ist dessen Wert festlegt welche Sätze aus der anderen Tabelle gebraucht werden.

Das steht ausser Frage. Eine Zwischentabelle zum Abbilden einer n:m-Beziehung ist auf jeden Fall der bessere Weg.
Mir ging es nur darum zu Erfahren, was der Cross Join anders mach (in der Situation) als der Left Join und ob ich beim Left Join auch das von IBExpert beschriebene Problem habe, dass erst so ein riesiges Kreuzprodukt aufgebaut wird, bevor die Where-Bedingungen greifen, oder ob das die Datenbank dann schon optimieren kann und erst mal die Datensätze nimmt, die laut Where Bedingung aus Tabelle T1 kommen bevor dann das Ganze T2 dazu gejoined wird.

[Delphi.Narium]

Zu Oraclezeiten (20+ Jahre her) hätte meine Lösung dann eher so ausgesehen:

SQL-Code:

select T1a.*,T2.*
from (select * from T1 where T1.Feld1 = 'Irgendwas') T1a
Left Join T2 On 1=1

Erst in einem Select maximal einschränken und dann das Ergebnis dieser Einschränkung mit den anderen Tabellen joinen.

(Hat manchen Tag Laufzeit in Produktivsystemen eingespart).

[MyRealName]

Das Einschränken würde ja über einen CTE auch funktionieren, welche Firebird unterstützt. Wie gesagt, beid er einen Tabelle geht es um max. 10 Einträge.

[Uwe Raabe]

Ich versuche es mal so zu formulieren, wie ich es verstanden habe:

• Es gibt nur einen Kunden (der für den es die Datenbank überhaupt gibt)
• Es gibt mehrere Lieferadressen
• Es gibt keine Einschränkung der Lieferaddressen für ein Property

Die im ersten Post gezeigte Query listet also jedes Property genau so viel mal auf wie es Lieferadressen gibt. Also in der Art:

Property1, Lieferadresse1
Property1, Lieferadresse2
Property1, Lieferadresse3
...
Property2, Lieferadresse1
Property2, Lieferadresse2
Property2, Lieferadresse3
...
Property3, Lieferadresse1
Property3, Lieferadresse2
Property3, Lieferadresse3
...

Dann brauchst du auch keine weiteren Maßnahmen ergreifen.