Grades

SQL: „Implizierter JOIN“ als Alternative für den „INNER JOIN“

In MariaDB sowie auch MySQL gibt es eine kürzere und im ersten Augenblick „einfachere“ Schreibweise für INNER JOIN, die besonders Anfänger präferieren. Diese Variante wird impliziter JOIN genannt, da man die Schlüsselwörter „JOIN … ON …“ hierbei weglassen kann.

Implizite JOINs sind jedoch eine ältere, nicht empfohlene Methode, um Tabellen in SQL miteinander zu verbinden. Dabei werden die Tabellen durch ein Komma getrennt, und die Verknüpfung der Tabellen erfolgt in der WHERE-Klausel. Obwohl sie in vielen SQL-Datenbanken funktionieren, gelten sie heute als veraltet. Da diese alte Schreibweise in vielen Anleitungen (= Tutorials) vorkommt und in bestehenden Anwendungen weitverbreitet ist, stellen wir diese hier vor, damit du diese erkennen und gegebenenfalls ersetzen kannst.

Impliziter JOIN in MariaDB und MySQL

Statt also den INNER JOIN explizit auszuschreiben, kannst du die Tabellen mit einem Komma trennen und die Verknüpfungsbedingung über die WHERE-Klausel definieren. Die Syntax sieht dann so aus:

# SQL-Abfrage
SELECT tabelle1.spalte1, tabelle2.spalte2
FROM tabelle1, tabelle2
WHERE tabelle1.spalte = tabelle2.spalte;

Beispiel für einen impliziten JOIN

Nehmen wir wieder die Tabellen „Personen“ und „Adressen“. Wir möchten alle Personen und ihre Städte miteinander verknüpfen. Die Abfrage mit dem impliziten JOIN sieht so aus:

SELECT Personen.Vorname, Personen.Nachname, Adressen.Stadt, Adressen.Land
FROM Personen, Adressen
WHERE Personen.ID = Adressen.PersonenID;

Ergebnis: | Vorname | Nachname | Stadt | Land | |———–|————|————|————| | Albert | Einstein | Princeton | USA | | Marie | Curie | Paris | Frankreich |

Vergleich: Impliziter JOIN vs. INNER JOIN

INNER JOIN:

SELECT Personen.Vorname, Personen.Nachname, Adressen.Stadt, Adressen.Land
FROM Personen
INNER JOIN Adressen
ON Personen.ID = Adressen.PersonenID;

Impliziter JOIN:

SELECT Personen.Vorname, Personen.Nachname, Adressen.Stadt, Adressen.Land
FROM Personen, Adressen
WHERE Personen.ID = Adressen.PersonenID;

Was sind die Probleme beim „impliziten JOIN“?

1. Mangelnde Lesbarkeit des Codes

Ein Hauptproblem bei impliziten JOINs ist die Unübersichtlichkeit, besonders bei komplexeren Abfragen, bei denen mehrere Tabellen miteinander verbunden werden. Beim impliziten JOIN werden die Tabellen einfach durch ein Komma aufgelistet, und die Verknüpfungslogik versteckt sich in der WHERE-Bedingung.

Beispiel: Impliziter JOIN

SELECT Personen.Vorname, Adressen.Stadt
FROM Personen, Adressen
WHERE Personen.ID = Adressen.PersonenID;

Vergleichen wir das gleiche Beispiel mit einem expliziten INNER JOIN:

SELECT Personen.Vorname, Adressen.Stadt
FROM Personen
INNER JOIN Adressen ON Personen.ID = Adressen.PersonenID;

Problem beim impliziten JOIN:

  • Es ist nicht klar, dass die Verbindung der beiden Tabellen erfolgt.
  • Die eigentliche Logik des Joinens versteckt sich in der WHERE-Bedingung. Gerade bei mehreren Bedingungen oder langen Abfragen wird es schwierig, die JOIN-Beziehungen zu erkennen.

2. Gefahr von unbeabsichtigten Cartesian Joins

Ein Cartesian Join (oder Kreuzprodukt) tritt auf, wenn keine korrekte Verknüpfung zwischen den Tabellen definiert wird. Jede Zeile der ersten Tabelle wird mit jeder Zeile der zweiten Tabelle kombiniert, was zu extrem vielen und oft falschen Ergebnissen führt.

Bei impliziten JOINs passiert ein Cartesian Join, wenn man vergisst, die Verknüpfungsbedingung in der WHERE-Klausel anzugeben.

Beispiel: Cartesian Join bei fehlender Bedingung

SELECT Personen.Vorname, Adressen.Stadt
FROM Personen, Adressen; -- Es fehlt die Verknüpfung

Ergebnis:

  • Jede Person wird mit jeder Adresse kombiniert, unabhängig davon, ob es eine Verbindung gibt.
  • Bei 5 Personen und 5 Adressen entstehen 25 Kombinationen – die meisten davon falsch.

Explizite JOINs verhindern solche Fehler, weil die Verknüpfung explizit im JOIN-Statement angegeben werden muss. Fehlt die Verknüpfung, meldet SQL den Fehler „ON-Klausel fehlt“.

3. Lückenhafte Semantik und Logik

Das Problem bei impliziten JOINs ist oft, dass JOIN-Bedingungen und Filterbedingungen in der WHERE-Klausel miteinander verschmelzen. Dadurch wird es schwierig, die Logik klar zu trennen und zu erkennen, was zur Verknüpfung von Tabellen dient und was zur Filterung der Ergebnisse.

Beispiel: Impliziter JOIN mit Vermischung

SELECT Personen.Vorname, Personen.Nachname, Adressen.Stadt
FROM Personen, Adressen
WHERE Personen.ID = Adressen.PersonenID
  AND Adressen.Stadt = 'Princeton';

In diesem Beispiel verschmelzen:

  • JOIN-Bedingung: Personen.ID = Adressen.PersonenID (logische Verbindung der Tabellen zur Verknüpfung).
  • Filterbedingung: Adressen.Stadt = 'Princeton' (Anzeige nur von Einträgen aus Princeton).

Es ist schwer zu erkennen, welche Bedingungen für die Verknüpfung der Tabellen verantwortlich sind und welche rein der Filterung dienen. Besonders komplex wird das bei mehreren Tabellen und Bedingungen.

Expliziter JOIN zur Verbesserung der Lesbarkeit

Der gleiche Query könnte als expliziter JOIN klarer und strukturierter formuliert werden:

SELECT Personen.Vorname, Personen.Nachname, Adressen.Stadt
FROM Personen
INNER JOIN Adressen
ON Personen.ID = Adressen.PersonenID
WHERE Adressen.Stadt = 'Princeton';

Hier sind die Rollen klar:

  • Die JOIN-Bedingung (ON Personen.ID = Adressen.PersonenID) wird separat verwaltet.
  • Die Filterbedingung (WHERE Adressen.Stadt = 'Princeton') steht für die Auswahl der Daten.

Vorteile:

  1. Es wird vollständig klar, welche Klausel der Logik des JOIN dient und welche für die Filterung nach Princeton verantwortlich ist.
  2. Änderungen in der Verknüpfung oder den Filtern sind einfacher umzusetzen, ohne versehentlich die JOIN-Logik zu zerstören.
  3. Die Abfrage wird lesbarer und verständlicher – besonders für Developer, die neu zum Projekt hinzustoßen.

Beispiel: Probleme mit mehreren Bedingungen

Nehmen wir eine komplexe Abfrage, bei der eine dritte Tabelle „Berufe“ hinzugefügt wird:

Bei einem impliziten JOIN:

SELECT Personen.Vorname, Berufe.Beruf, Adressen.Stadt
FROM Personen, Adressen, Berufe
WHERE Personen.ID = Adressen.PersonenID
  AND Personen.ID = Berufe.PersonenID
  AND Adressen.Land = 'USA';

Zu erkennen, welche Bedingungen für die Verknüpfung und welche für die Filterung da sind, ist hier zunehmend schwieriger.

Der explizite JOIN löst dieses Problem besser:

SELECT Personen.Vorname, Berufe.Beruf, Adressen.Stadt
FROM Personen
INNER JOIN Adressen ON Personen.ID = Adressen.PersonenID
INNER JOIN Berufe ON Personen.ID = Berufe.PersonenID
WHERE Adressen.Land = 'USA';
  • Mit ON wird klar, welche Verknüpfung verwendet wird – hier jeweils die Spalten Personen.ID in beiden Tabellen.
  • Zusätzliche Filter, wie Adressen.Land = 'USA', stehen deutlich abgetrennt in der WHERE-Klausel.

Fazit zu Semantik und Logik

  • Implizite JOINs haben keine klare Strukturierung: Eine Vermischung aus Filter- und Verknüpfungslogik macht SQL schwieriger verständlich und fehleranfälliger.
  • Explizite JOINs fördern klare und logisch strukturierte Abfragen gemäß moderner SQL-Praktiken. Sie helfen dir, den Code sauberer, wartbarer und lesbarer zu halten.

4. Moderner SQL-Standard favorisiert explizite JOINs

In moderner SQL-Praxis und SQL-Standards (wie SQL-92) werden explizite JOINs (INNER JOIN, LEFT JOIN, RIGHT JOIN, usw.) klar bevorzugt. Sie bieten:

  • Strukturen, die leicht zu lesen und zu warten sind: Entwickler können klar erkennen, wie Tabellen miteinander verbunden sind.
  • Bessere Kompatibilität mit komplexeren Abfragen: Moderne Datenbanken bauen oft auf expliziten JOINs auf, insbesondere bei OUTER JOINs und mehrstufigen Kombinationen.
  • Erweiterbarkeit: Wenn neue Bedingungen oder Tabellen hinzukommen, lassen sich explizite JOINs leichter erweitern.

Da implizite JOINs vor den SQL-92-Standards verwendet wurden, gelten sie als veraltet. Wer sich heute mit SQL beschäftigt, wird in Unterrichtsmaterialien, Tutorials oder Büchern fast immer explizite JOINs finden – implizite JOINs sind nur noch selten Thema.

5. Keine Unterstützung für OUTER JOINs

Implizite JOINs können nur einfache Tabellenverknüpfungen wie den „INNER JOIN“ ausdrücken. Wenn es jedoch um komplexere JOINs wie LEFT JOIN, RIGHT JOIN oder FULL JOIN geht, versagen sie vollständig. Das schränkt ihren Anwendungsbereich erheblich ein. Zudem ist der Umstieg von einem impliziten JOIN auf einen komplexen OUTER JOIN erheblich schwieriger, da man komplett auf die expliziten JOINs wechseln müsste.

6. Wartbarkeit in großen Projekten

In Projekten mit vielen Tabellen und Filtern wird die Wartung von SQL-Abfragen mit impliziten JOINs extrem schwierig. Häufig weiß man bei der Fehlersuche nicht, ob Fehler durch Verbindungsprobleme (JOIN-Bedingungen) oder Filterbedingungen (WHERE) verursacht wurden, da alles zusammengeworfen ist.

Mit dem expliziten JOIN kannst du JOIN-Bedingungen und Filter klar trennen:

  • Verwende ON für die Logik der Verbindungen zwischen Tabellen.
  • Nutze WHERE, um die Ergebnisse weiter zu filtern (z. B. nur bestimmte Datensätze anzuzeigen).

Fazit: Warum du implizite JOINs vermeiden solltest

Nachteile von impliziten JOINs:

  1. Unleserlichkeit: Große und komplexe Abfragen werden schnell unübersichtlich.
  2. Fehleranfälligkeit: Ein vergessenes Kriterium in der WHERE-Bedingung führt schnell zu kartesischen Produkten.
  3. Moderne Datenbanken setzen auf explizite JOINs: Implizite JOINs gelten als alte Methode und passen nicht zum modernen SQL-Standard.
  4. Verwirrende Trennung von JOINs und Filtern: JOIN-Logik und Filterbedingungen sind schwieriger zu unterscheiden.
  5. Keine Unterstützung von OUTER JOINs: Implizite JOINs sind auf einfache Verknüpfungen beschränkt.

Empfehlung:

Verwende stets explizite JOINs, um klar zu zeigen, wie Tabellen miteinander verknüpft sind. Explizite JOINs sind nicht nur lesbarer und wartbarer, sondern auch unverzichtbar für moderne Anwendungen, die komplexe Verknüpfungen benötigen.

Insgesamt ist der implizite JOIN nur eine Abkürzung oder alternative Schreibweise, wenn du einfachere Abfragen erstellst. Für gute Codequalität sollte der explizite INNER JOIN die Standardwahl bleiben – besonders bei mehr als zwei Tabellen!