Ein INNER JOIN ist ein Begriff aus der Datenbankabfrage (SQL). Er wird verwendet, um Datensätze aus zwei (oder mehr) Tabellen zu kombinieren – und zwar nur die Datensätze, bei denen es in beiden Tabellen passende Werte gibt.

Beispiel:

Du hast zwei Tabellen:

Tabelle: Kunden

Tabelle: Bestellungen

Jetzt willst du wissen, welche Kunden Bestellungen gemacht haben. Dafür brauchst du nur die Kunden, die in beiden Tabellen vorkommen.

SQL mit INNER JOIN:

SELECT Kunden.Name, Bestellungen.Produkt
FROM Kunden
INNER JOIN Bestellungen ON Kunden.KundenID = Bestellungen.KundenID;

Ergebnis:

Erklärung:

• Clara hat nichts bestellt → wird nicht angezeigt.

• Die Bestellung mit KundenID 4 hat keinen passenden Kunden → wird ebenfalls ignoriert.

Kurz gesagt:

Ein INNER JOIN zeigt nur die Datensätze, bei denen es Übereinstimmungen in beiden Tabellen gibt.

Ein expliziter Join ist eine klare, direkte Formulierung eines Joins in einer SQL-Abfrage, bei der die Join-Art (z. B. INNER JOIN, LEFT JOIN, RIGHT JOIN, FULL OUTER JOIN) ausdrücklich im SQL-Statement genannt wird.

Beispiel für einen expliziten Join:

SELECT *
FROM kunden
INNER JOIN bestellungen
ON kunden.kunden_id = bestellungen.kunden_id;

Hier sieht man deutlich:

• Welche Tabellen verbunden werden (kunden, bestellungen)

• Welche Join-Art verwendet wird (INNER JOIN)

• Welche Bedingung für den Join gilt (ON kunden.kunden_id = bestellungen.kunden_id)

Im Gegensatz dazu: Impliziter Join

Ein impliziter Join ist die ältere Schreibweise mit einem Komma in der FROM-Klausel, wobei die Join-Bedingung in der WHERE-Klausel steht:

SELECT *
FROM kunden, bestellungen
WHERE kunden.kunden_id = bestellungen.kunden_id;

Diese Variante ist funktional gleich, aber weniger klar und nicht für komplexe Joins geeignet.

Vorteile des expliziten Joins:

• Lesbarer und strukturierter, vor allem bei mehreren Tabellen

• Klarere Trennung von Join-Bedingungen und Filterbedingungen (ON vs. WHERE)

• Empfohlen in moderner SQL-Programmierung

Ein impliziter Join ist eine Art, Tabellen in SQL zu verknüpfen, ohne das Schlüsselwort JOIN explizit zu verwenden. Stattdessen wird der Join über die WHERE-Klausel ausgedrückt.

Beispiel für einen impliziten Join:

SELECT *
FROM kunden, bestellungen
WHERE kunden.kunden_id = bestellungen.kunden_id;

In diesem Beispiel werden die Tabellen kunden und bestellungen durch die Bedingung in der WHERE-Klausel miteinander verknüpft.

Im Vergleich dazu ein expliziter Join:

SELECT *
FROM kunden
JOIN bestellungen ON kunden.kunden_id = bestellungen.kunden_id;

Unterschiede:

Wann wird ein impliziter Join verwendet?

Früher war das der Standard, aber heute wird der explizite Join empfohlen, da er lesbarer, strukturierter und weniger fehleranfällig ist – besonders bei komplexen Abfragen mit mehreren Tabellen.

Eine Materialized View (auf Deutsch: „materialisierte Sicht“) ist ein spezielles Datenbankobjekt, das das Ergebnis einer SQL-Abfrage dauerhaft speichert – im Gegensatz zu einer normalen View, die bei jeder Abfrage dynamisch berechnet wird.

Eigenschaften einer Materialized View:

• Speicherung auf Festplatte: Die Daten der Abfrage werden tatsächlich gespeichert, nicht nur die Abfrage selbst.

• Schnellere Abfragen: Da die Daten bereits berechnet und gespeichert sind, können Anfragen deutlich schneller beantwortet werden.

• Aktualisierung notwendig: Da sich die zugrundeliegenden Daten ändern können, muss die Materialized View explizit oder automatisch aktualisiert (refreshed) werden, um aktuell zu bleiben.

Vergleich: View vs. Materialized View

Beispiel:

-- Erstellen einer Materialized View in PostgreSQL
CREATE MATERIALIZED VIEW top_customers AS
SELECT customer_id, SUM(order_total) AS total_spent
FROM orders
GROUP BY customer_id;

Um die Daten zu aktualisieren:

REFRESH MATERIALIZED VIEW top_customers;

Wann ist sie sinnvoll?

• Bei komplexen Aggregationen, die häufig gebraucht werden

• Wenn Performance wichtiger ist als Echtzeit-Aktualität

• In Data Warehouses oder Reporting-Systemen

ACID ist ein Akronym, das vier zentrale Eigenschaften beschreibt, die für die Zuverlässigkeit von Datenbanktransaktionen in einem Datenbankmanagementsystem (DBMS) entscheidend sind. Diese Eigenschaften gewährleisten die Integrität der Daten und die Konsistenz der Datenbank auch bei Fehlern oder Systemabstürzen. ACID steht für:

1. Atomicity (Atomarität):

   • Jede Transaktion wird als eine unteilbare Einheit betrachtet. Das bedeutet, entweder wird die gesamte Transaktion vollständig ausgeführt, oder gar nicht. Wenn ein Teil der Transaktion fehlschlägt, wird die gesamte Transaktion rückgängig gemacht und die Datenbank bleibt in einem konsistenten Zustand.

2. Consistency (Konsistenz):

   • Jede Transaktion führt die Datenbank von einem konsistenten Zustand in einen anderen konsistenten Zustand. Das bedeutet, dass nach Abschluss einer Transaktion alle Integritätsbedingungen der Datenbank erfüllt sind. Konsistenz stellt sicher, dass keine Transaktion die Datenbank in einen ungültigen Zustand versetzt.

3. Isolation (Isolation):

   • Transaktionen werden isoliert voneinander ausgeführt. Das bedeutet, dass die Ausführung einer Transaktion so erfolgen muss, als ob sie die einzige Transaktion in der Datenbank ist. Die Ergebnisse einer laufenden Transaktion sind für andere Transaktionen nicht sichtbar, bis die Transaktion abgeschlossen ist. Dies verhindert, dass parallele Transaktionen einander beeinflussen und zu Inkonsistenzen führen.

4. Durability (Dauerhaftigkeit):

   • Nach Abschluss einer Transaktion (d.h., wenn sie „committed“ ist) bleiben die Änderungen dauerhaft erhalten, selbst im Falle eines Systemabsturzes oder eines anderen Fehlers. Die Dauerhaftigkeit wird in der Regel durch das Schreiben der Änderungen auf nicht-flüchtige Speicher wie Festplatten sichergestellt.

Beispiel zur Verdeutlichung

Stellen wir uns vor, wir haben eine Bankdatenbank mit zwei Konten: Konto A und Konto B. Eine Transaktion überweist einen Betrag von 100 Euro von Konto A auf Konto B. Die ACID-Eigenschaften gewährleisten Folgendes:

• Atomicity: Wenn die Überweisung aus irgendeinem Grund fehlschlägt (z.B. wegen eines Systemabsturzes), wird die gesamte Transaktion rückgängig gemacht. Konto A wird nicht belastet und Konto B erhält keinen Betrag.
• Consistency: Die Transaktion stellt sicher, dass die Gesamtmenge des Geldes in beiden Konten vor und nach der Transaktion gleich bleibt (wenn keine anderen Faktoren ins Spiel kommen). Falls Konto A ursprünglich 200 Euro und Konto B 300 Euro hatte, sollte das Gesamtsaldo von 500 Euro nach der Transaktion unverändert bleiben.
• Isolation: Wenn zwei Überweisungen gleichzeitig stattfinden, beeinflussen sie sich nicht gegenseitig. Jede Transaktion sieht die Datenbank so, als wäre sie die einzige laufende Transaktion.
• Durability: Sobald die Transaktion abgeschlossen ist, sind die Änderungen dauerhaft. Selbst wenn nach der Transaktion ein Stromausfall auftritt, bleibt der neue Kontostand von Konto A und Konto B erhalten.

Bedeutung von ACID

Die ACID-Eigenschaften sind entscheidend für die Zuverlässigkeit und Integrität von Datenbanktransaktionen, insbesondere in Systemen, die mit sensiblen Daten arbeiten, wie Finanzinstitutionen, E-Commerce-Plattformen und kritischen Geschäftsanwendungen. Sie helfen, Datenverlust und -beschädigung zu verhindern und stellen sicher, dass Daten konsistent und vertrauenswürdig bleiben.