Join mit mehreren Tabellen

[gamma_matrices]

Hallo,

ich möchte gerne 4 Tabellen verknüpfen, von denen 3 gemeinsamen Primary Key (pk) haben.
Habt ihr eine Idee wie man die 3 Tabellen kompakter joinen kann, statt was ich bereits gemacht habe?

select a.*, b.*, c.*
from tabelle a join tabelle b on
a.pk = b.pk join tabelle c on
c.pk = b.pk ...

Danke!

 

[R O G E R]

Was meinste mit kompakter Joinen?

Du hast jetzt ne Riesige Tabelle mit allen 3 Tabellen nebeneinander so zu sagen.

du kannst in dem select Befehl ja sagen, was du alles haben willst. Wenn man da Parameter weg lässt die man nicht braucht geht es auch schneller.

 

[gamma_matrices]

Kann man Zeile 2 - 4 irgendwie kompakter zusammenfassen?
Alle 3 Tables sind über dem selben PK miteinander verknüpft.
Ich würde gerne 2 joins hintereinander vermeiden wollen, da das jetzt nicht gerade elegant aussieht!

 

[madmax2010]

Schaut doch super aus ich wuerde aber empfehlen, die beim Namen zu nennen. nur weil du alles so kurz wie moeglisch schreibst, wird das laufzeitverhalten nicht besser.
kannst dir bei bedarf halt auch zwischentabellen oder Views bauen. Das ksotet auch keine Performance

 

[RalphS]

Nen view bauen und nur noch diesen fragen.

Als 1:1 relation kann man das auch einfach in eine Tabelle stecken, wenn nicht was anderes gegenspricht.

 

[R O G E R]

Was soll das bringen?

Was du natürlich machen kannst:

select a.*, b*, c*
from tabelle a join tabelle b on a.pk = b.pk join tabelle c on c.pk = b.pk

 

[Oelepoeto]

Nein, jede Tabelle muss logischerweise explizit dazu gejoined werden, weniger geht nicht. Du hast eh schon das 'inner' weggelassen, was nicht unbedingt sauber ist.

 

[RalphS]

Es gibt keinen outer join ohne entsprechendes keyword, das paßt.

 

[gamma_matrices]

Was soll das bringen?

Was du natürlich machen kannst:

select a.*, b*, c*
from tabelle a join tabelle b on a.pk = b.pk join tabelle c on c.pk = b.pk

Ergänzung (20. Mai 2021)

Alles klar, dann werde ich so doch lassen.
Lässt sich wohl nicht ganz vermeiden.

 

[Physikbuddha]

Da du nicht sagst, welche Datenbank du verwendest, kann man nur raten.
Mit MySQL könntest du es verkürzen:

SELECT * FROM a
NATURAL JOIN b
NATURAL JOIN c

 

[gamma_matrices]

Da du nicht sagst, welche Datenbank du verwendest, kann man nur raten.
Mit MySQL könntest du es verkürzen:

SELECT * FROM a
NATURAL JOIN b
NATURAL JOIN c

Oracle SQL Developer

 

[Physikbuddha]

Sorry, da bin ich raus
Edit: Aber auch Oracle scheint Natural Joins zu bieten: https://docs.oracle.com/javadb/10.8.3.0/ref/rrefsqljnaturaljoin.html

Bei SQL Server weiß ich, dass es ihn nicht gibt.

Bedenke aber, dass es ansonsten keine identisch benamten Spalten in deinen Tabellen geben darf, da ansonsten der Join über alle Spalten gemacht wird.

Natural Joins sind daher etwas verpönt, da sich deine Abfragen schnell ändern können, wenn an der Datenstruktur geändert wird.

 

[Raijin]

Darf man fragen was denn genau das Problem ist? Ist dir das SQL-Statement zu komplex, ist es zu lang zum Lesen, dauert es zu lange bei der Ausführung, ist das Ergebnis zu groß oder liefert es nicht die erwarteten Ergebnisse?


Man muss SQL natürlich schon die notwendigen Informationen geben und wenn ein Statement dadurch komplex und lang wird, dann ist das eben so. Tendenziell formuliert man das Statement sogar noch etwas länger, weil man Tabellennamen gerne mit "as xy" abkürzt, um sich bei den joins den kompletten Namen sparen zu können.

Abgesehen davon kann man sicherlich auch die Tabellen als solche einer Revision unterziehen, um beispielsweise auf die Normalform(en) zu prüfen. Unter Umständen ist eine der Tabellen gar überflüssig, weil sie in einer der anderen aufgehen kann. Das musst du allerdings selbst beurteilen, es sei denn du gibst Beispiele für die Tabellen.

 

[gamma_matrices]

Darf man fragen was denn genau das Problem ist? Ist dir das SQL-Statement zu komplex, ist es zu lang zum Lesen, dauert es zu lange bei der Ausführung, ist das Ergebnis zu groß oder liefert es nicht die erwarteten Ergebnisse?


Man muss SQL natürlich schon die notwendigen Informationen geben und wenn ein Statement dadurch komplex und lang wird, dann ist das eben so. Tendenziell formuliert man das Statement sogar noch etwas länger, weil man Tabellennamen gerne mit "as xy" abkürzt, um sich bei den joins den kompletten Namen sparen zu können.

Abgesehen davon kann man sicherlich auch die Tabellen als solche einer Revision unterziehen, um beispielsweise auf die Normalform(en) zu prüfen. Unter Umständen ist eine der Tabellen gar überflüssig, weil sie in einer der anderen aufgehen kann. Das musst du allerdings selbst beurteilen, es sei denn du gibst Beispiele für die Tabellen.

Ist eher rein kosmetischer Natur und nicht wegen Performance. Aber ich werde das so belassen und nehme doch zur Kenntnis, dass hier Richtung Kompaktheit nichts mehr rauszuholen ist.

 

[Physikbuddha]

@gamma_matrices Mit den Natural Joins kriegst du es wie gesagt kompakter, aber halt auf Kosten der Verschleierung, welche Spalten genau gematcht werden. Beispiel hab ich dir gegeben.

 

[Raijin]

Hm.. Also wenn ich "oracle sql natural join" google, bekomme ich zumindest einige Ergebnisse. Kann sein, dass das nicht nur bei mysql geht. Probier es doch einfach mal aus.

Wobei ich persönlich eher weniger auf solche Verschleierungen stehe, wenn ich ehrlich bin. Sofern es klappt, wäre es aber immerhin kompakter, so wie du es möchtest

*edit
Sehe gerade, dass @Physikbuddha das bereits reineditiert hat.

 

[Murray B.]

Also meine Abfragen sind gerne mal mehrere hundert Zeilen lang (keine Berechtigung für Views in der Datenbank, daher in MS SQL per CTEs), ich finde deine Query daher sehr kompakt und gut lesbar.

Kürzer geht es nicht, es sei denn, du kannst, wie bereits gesagt, die Tabellen zu einer einzigen zusammenfügen. Aber je nachdem, welche Daten darin gespeichert sind und ob die einzelnen Tabellen bereits in Normalform sind, kann das auch eine Verschlechterung der Datenstruktur bedeuten.

 

[Phrasendreher]

Vielleicht willst Du darauf hinaus, dass Du den

join tabelle c on c.pk=b.pk

-Teil mit

USING (pk)

abkürzen kannst, also etwa so:

select a.*, b*, c* from tabelle a join tabelle b USING (pk) join tabelle c USING (pk)

USING macht im Grunde das Gleiche wie NATURAL JOIN, nur dass Du die Spaltennamen für die Spaltenzuordnung in der Klammer explizit angibst.

 

[RalphS]

@Raijin da ist nix Normalform => das sind entweder 1:1 Relationen (selber PK, faszinierenderweise über mehr als zwei Tabellen) oder wir haben ein XY Problem.

Ansonsten:

YOU DO NOT USE NATURAL OR USING (PK).

Problem A:
Tabelle Mitarbeiter
ID Name Vorname Abteilung
1 Pan Peter Flighting
2 Darling Wendy Barking
3 Panther Pink Yowling

Tabelle Kunden
ID Name Vorname
1 Lenz Maximilian
2 Just Christopher
3 Gleiss Marion

SELECT Kunden.*, Mitarbeiter.* FROM Kunden NATURAL JOIN Mitarbeiter;
=> ???


Problem B:
Tabelle Rechnung
ID Kunde_ID Datum
1 1 gestern
2 1 heute
3 2 morgen

SELECT * FROM Rechnung JOIN Kunden USING (id);
==> ????



Lösung:
1. Ordentlichen Datenbankentwurf erstellen. Wenn der nicht total geheim ist, hier offenlegen. Irgendwer findet sich bestimmt für Anhaltspunkte, ob man 1:1 lassen kann, ob und wo 1:n und ob und wo m:n Relationen implementiert werden können oder sollen oder sogar müssen.


2. SQL Abfragen nicht auf KURZ trimmen, sondern auf EXAKT.
Wenn eine simple Änderung des Datenbankschemas dazu führt, sei es durch neue oder umbenannte Spalten, daß meine Abfrage(n) jetzt andere Werte liefern...
.... dann habe ich etwas grundlegend falsch gemacht.

 

[Raijin]

@Raijin da ist nix Normalform => das sind entweder 1:1 Relationen (selber PK, faszinierenderweise über mehr als zwei Tabellen) oder wir haben ein XY Problem.

Das ist auch meine Befürchtung.