Ein Prepared Statement (auch vorbereitetes Statement genannt) ist eine Technik in der Programmierung, insbesondere bei der Arbeit mit Datenbanken, um SQL-Abfragen sicherer und effizienter auszuführen.

1. Was passiert bei einem Prepared Statement?

Ein Prepared Statement besteht aus zwei Schritten:

1. Vorbereitung der SQL-Abfrage mit Platzhaltern
   Beispiel in SQL:

SELECT * FROM users WHERE username = ? AND password = ?

• (In manchen Sprachen nutzt man auch :username oder andere Platzhalter)

• Bindung der Parameter und Ausführung
  Die echten Werte werden später „gebunden“, z. B.:

$stmt->bind_param("ss", $username, $password);
$stmt->execute();

2. Vorteile

✅ Sicherer vor SQL-Injection:
Benutzereingaben werden nicht direkt in die SQL eingebaut, sondern separat behandelt.

✅ Schneller bei Wiederholungen:
Die SQL-Abfrage wird vom Datenbankserver einmal geparst und kann mehrfach effizient ausgeführt werden (z. B. bei Schleifen).

$conn = new mysqli("localhost", "user", "pass", "database");
$stmt = $conn->prepare("SELECT * FROM users WHERE email = ?");
$stmt->bind_param("s", $email); // "s" für string
$email = "beispiel@example.com";
$stmt->execute();
$result = $stmt->get_result();

Kurz gesagt:

Ein Prepared Statement trennt SQL-Logik von Benutzereingaben und schützt so vor Sicherheitslücken wie SQL-Injection. Es ist eine Best Practice beim Umgang mit Datenbanken.

Ein Outer Join ist ein Begriff aus der Datenbankabfrage (meist in SQL) und bezeichnet eine spezielle Art, zwei Tabellen miteinander zu verknüpfen – auch dann, wenn keine passenden Datensätze in einer der Tabellen vorhanden sind.

Arten von Outer Joins:

1. LEFT OUTER JOIN (oder einfach: LEFT JOIN):
   → Gibt alle Datensätze aus der linken Tabelle zurück, auch wenn es keine passenden Datensätze in der rechten Tabelle gibt.
   → Nicht passende Werte aus der rechten Tabelle werden mit NULL aufgefüllt.

2. RIGHT OUTER JOIN (oder: RIGHT JOIN):
   → Gibt alle Datensätze aus der rechten Tabelle zurück, auch wenn es keine passenden in der linken gibt.
   → Nicht passende Werte aus der linken Tabelle werden mit NULL ergänzt.

3. FULL OUTER JOIN:
   → Gibt alle Datensätze aus beiden Tabellen zurück.
   → Wo keine Übereinstimmung vorliegt, wird mit NULL ergänzt.

Beispiel:

Angenommen, du hast zwei Tabellen:

• Kunden

  Kundennr	Name
  1	Anna
  2	Bernd
  3	Clara

• Bestellungen

  Bestellnr	Kundennr	Produkt
  101	2	Buch
  102	4	Lampe

LEFT JOIN (Kunden LEFT JOIN Bestellungen ON Kunden.Kundennr = Bestellungen.Kundennr)

Transaction Control Language (TCL) ist ein Teil der SQL-Sprache, der verwendet wird, um die Kontrolle über Transaktionen in einer Datenbank zu ermöglichen. Eine Transaktion ist eine logische Einheit von Arbeit, die eine oder mehrere SQL-Anweisungen umfasst – oft Insert-, Update- oder Delete-Befehle –, die zusammen ausgeführt werden sollen.

TCL stellt Befehle bereit, um sicherzustellen, dass Transaktionen korrekt abgeschlossen oder im Fehlerfall rückgängig gemacht werden.

Die wichtigsten TCL-Befehle:

BEGIN;

UPDATE konto SET saldo = saldo - 100 WHERE konto_id = 1;
UPDATE konto SET saldo = saldo + 100 WHERE konto_id = 2;

COMMIT;

→ Beide Updates werden gemeinsam abgeschlossen. Wenn ein Fehler auftritt, könnte man ROLLBACK ausführen, um beide Änderungen zu verwerfen.

Wichtig:

TCL-Befehle wirken nur bei Datenbank-Systemen, die Transaktionen unterstützen (z. B. PostgreSQL, Oracle, MySQL mit InnoDB).

Data Control Language (DCL) ist ein Teilbereich von SQL, der sich mit der Verwaltung von Zugriffsrechten und Berechtigungen in einer Datenbank beschäftigt. Mit DCL-Befehlen wird gesteuert, wer was in der Datenbank tun darf.

Die wichtigsten DCL-Befehle:

GRANT SELECT, INSERT ON Kunden TO Benutzer123;
REVOKE INSERT ON Kunden FROM Benutzer123;

Die Data Manipulation Language (DML) ist ein Teilbereich der SQL (Structured Query Language), der für das Bearbeiten von Daten in einer Datenbank verwendet wird. Mit DML können Benutzer Daten einfügen, abfragen, ändern und löschen – also genau das, was man im Alltag mit Daten in einer Datenbank machen möchte.

Zu den wichtigsten DML-Befehlen gehören:

Beispiel:

-- Einfügen
INSERT INTO kunden (name, stadt) VALUES ('Müller', 'Berlin');

-- Abfragen
SELECT * FROM kunden WHERE stadt = 'Berlin';

-- Aktualisieren
UPDATE kunden SET stadt = 'Hamburg' WHERE name = 'Müller';

-- Löschen
DELETE FROM kunden WHERE name = 'Müller';

Wichtig:

• DML arbeitet mit den Daten innerhalb der Tabellen, nicht mit der Struktur der Tabellen selbst (dafür gibt es die Data Definition Language, DDL).

• DML-Befehle können oft rückgängig gemacht werden (z. B. durch ROLLBACK), sofern Transaktionen unterstützt werden.

Kurz gesagt: DML ist das Werkzeug, mit dem du Daten in einer Datenbank lebendig hältst – also ständig anpasst, liest und veränderst.

DQL steht für Data Query Language und ist ein Teil der SQL-Sprache (Structured Query Language). Sie dient dazu, Daten aus einer Datenbank abzufragen, ohne sie zu verändern.

Hauptmerkmal von DQL:

• Nur lesend: Mit DQL werden Daten abgefragt, aber nicht eingefügt, verändert oder gelöscht.

• Der zentral verwendete Befehl ist:

SELECT

Beispiel:

SELECT name, geburtsdatum FROM kunden WHERE stadt = 'Berlin';

Dieser Befehl liest die Namen und Geburtsdaten aller Kunden aus, die in Berlin wohnen – verändert aber nichts an den Daten.

DQL im Vergleich zu anderen SQL-Teilen:

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