Join mit mehreren Tabellen

[BeBur]

Wenn schon sollte man auf Lesbarkeit optimieren, nicht auf "kürze", so dass das Wesen der Abfrage möglichst schnell erfassbar ist. Also diese a, b, c Geschichte ist jetzt hoffentlich nur für hier und nicht in der realen Abfrage. Ein vernünftiger Editor macht vermutlich auch direkt sinnvolle Einrückungen, wenn man die newlines an sinnvollen Stellen macht.

 

[Murray B.]

Wenn schon sollte man auf Lesbarkeit optimieren, nicht auf "kürze", so dass das Wesen der Abfrage möglichst schnell erfassbar ist.

Volle Zustimmung.
"Sprechende" Namen für Tabellen und deren Aliase, einheitliche Nomenklatur für alle Spaltennamen, vernünftiges Layout für den SQL-Code, ordentliche Kommentare, die erläutern, warum man etwas tut (und nicht was man tut), Aufteilung in übersichtliche Subqueries oder Views (bei MS SQL bieten sich CTEs an).
Und wenn man dann noch die von der jeweiligen Datenbank abhängigen Best Practices berücksichtigt, was Performance und Effizienz betrifft, kann man auch hochkomplexe Abfragen gut in den Griff bekommen.

 

[mental.dIseASe]

Wenn schon sollte man auf Lesbarkeit optimieren, nicht auf "kürze", so dass das Wesen der Abfrage möglichst schnell erfassbar ist.

Ein Daumen hoch aus der Wartung.

 

[gamma_matrices]

Wenn schon sollte man auf Lesbarkeit optimieren, nicht auf "kürze", so dass das Wesen der Abfrage möglichst schnell erfassbar ist. Also diese a, b, c Geschichte ist jetzt hoffentlich nur für hier und nicht in der realen Abfrage. Ein vernünftiger Editor macht vermutlich auch direkt sinnvolle Einrückungen, wenn man die newlines an sinnvollen Stellen macht.

Diese max. Abspeckungen an Namensangaben diente nur für hier als Analogon für die Anwendung auf realer Ebene.

Ergänzung (21. Mai 2021)

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

Alle 3 Tabellen sind mit dem selben PK ( hier konkret: VertragID) verknüpft, wobei Tabelle a eine 1:n Relation zu b und c darstellt.Hier die PKs der Tabellen:
a ==> pk_a
b ==> pk_b, pk_a
c ==> pk_c, pk_a

 

[BeBur]

Vorschlag/Beispiel:

SELECT a.*,
       b.*,
       c.*
FROM tabelle a
     JOIN tabelle b
         ON a.pk = b.pk
     JOIN tabelle c
         ON c.pk = b.pk
WHERE ...

Allein schon, dass offenbar niemand das fehlende Komma bemerkt hat (zumindest hat es niemand kommentiert) belegt schon ganz gut, dass Übersichtlichkeit immer Vorrang haben sollte. Es gibt keinen Grund, das irgendwie anders zu machen und auch keinen Grund einen Query mit natural join zu bauen, der zu Problemen führen kann.

 

[gamma_matrices]

Vorschlag/Beispiel:

SELECT a.*,
       b.*,
       c.*
FROM tabelle a
     JOIN tabelle b
         ON a.pk = b.pk
     JOIN tabelle c
         ON c.pk = b.pk
WHERE ...

Allein schon, dass offenbar niemand das fehlende Komma bemerkt hat (zumindest hat es niemand kommentiert) belegt schon ganz gut, dass Übersichtlichkeit immer Vorrang haben sollte. Es gibt keinen Grund, das irgendwie anders zu machen und auch keinen Grund einen Query mit natural join zu bauen, der zu Problemen führen kann.

Mit anderen Worten, einfach so lassen wie es initial angegeben wurde! Übrigens, danke für den Hinweis, wird gleich korrigiert!

 

[BeBur]

Mit anderen Worten, einfach so lassen wie es initial angegeben wurde!

Nein, Absätze und Einrückung sollten noch eingefügt werden.

danke für den Hinweis, wird gleich korrigiert!

Gern, vielleicht überzeugt das ja zusätzlich noch von dem Argument, dass man lieber mehr Zeichen/Zeilen verwendet, solange es denn der Übersicht dient :-)

 

[floq0r]

Noch ein Tipp für später: Lieber explizite Spaltennamen als Wildcards (*) verwenden.
1. Man sieht auf einen Blick was man selektiert bekommt
2. Wenn man später Columns hinzufügt ohne alle Indizes bearbeiten zu wollen führt eine Selektion mit Wildcards oft zu Key Lookups im Execution Plan wenn die neuen Columns nicht in den (composite) indexes inkludiert sind.