FAQ-Glossar zur SQL Schulung

In der SQL Schulung beschreiben Tabellen (Relationen) fachliche Objekte als Zeilen (Tupel) mit Spalten (Attribute). Beziehungen zwischen Tabellen werden über Schlüssel hergestellt. Ziel ist eine klare, widerspruchsfreie Datenbasis, auf der Abfragen reproduzierbare Ergebnisse liefern.

Beispielcode aus der SQL Schulung:

-- Beispieltabellen; automatische Schlüsselgenerierung ist produktspezifisch.
CREATE TABLE teilnehmer (
  id       INTEGER PRIMARY KEY,
  name     TEXT NOT NULL,
  email    TEXT UNIQUE NOT NULL
);

CREATE TABLE buchung (
  id             INTEGER PRIMARY KEY,
  teilnehmer_id  INTEGER NOT NULL REFERENCES teilnehmer(id),
  kurs           TEXT NOT NULL,
  datum          DATE NOT NULL
);

Zwei Tabellen mit Primär- und Fremdschlüssel bilden eine einfache, konsistente Struktur für Schulungsbuchungen.

Tabellen sind strukturierte Sammlungen gleichartiger Zeilen. Jede Zeile enthält Werte je Spalte. In der SQL Schulung legen wir Spaltentypen so fest, dass sie den realen Daten entsprechen (z. B. DATE für Termine).

Beispielcode aus der SQL Schulung:

CREATE TABLE kurs (
  id    INTEGER PRIMARY KEY,
  titel TEXT    NOT NULL,
  tage  INTEGER NOT NULL
);

Die Spaltentypen bilden den fachlichen Inhalt ab. Constraints (NOT NULL) sichern Datenqualität.

Ein Primärschlüssel identifiziert eine Zeile eindeutig. In der SQL Schulung unterscheiden wir natürliche und künstliche Schlüssel. Die automatische Schlüsselgenerierung wird produktspezifisch eingerichtet und nicht als systemübergreifend identische Syntax behandelt.

Beispielcode aus der SQL Schulung:

CREATE TABLE raum (
  raum_nr   TEXT PRIMARY KEY,
  plaetze   INT  NOT NULL
);

Hier ist die Raumnummer eindeutig. Alternativ nutzen wir künstliche IDs, wenn natürliche Schlüssel instabil sind.

Fremdschlüssel beschreiben referenzielle Integritätsregeln zwischen Tabellen. Ob und wie ein Datenbanksystem deklarierte Fremdschlüssel prüft, hängt von Produkt und Konfiguration ab; in SQLite muss die Fremdschlüsselprüfung pro Verbindung aktiviert werden. Lösch- und Update-Regeln wie ON DELETE werden bewusst festgelegt.

Beispielcode aus der SQL Schulung:

CREATE TABLE teilnahme (
  id            INTEGER PRIMARY KEY,
  teilnehmer_id INTEGER NOT NULL REFERENCES teilnehmer(id) ON DELETE CASCADE,
  kurs_id       INTEGER NOT NULL REFERENCES kurs(id)
);

Beim Löschen eines Teilnehmers werden zugehörige Teilnahmen mit gelöscht (CASCADE).

Datentypen werden passend zum fachlichen Inhalt gewählt, aber Typnamen und Speicherregeln unterscheiden sich zwischen Datenbanksystemen. TEXT/VARCHAR, INTEGER, NUMERIC/DECIMAL, DATE/TIMESTAMP und BOOLEAN sind daher immer im Produktkontext zu prüfen. SQLite verwendet dynamische Typisierung mit Typaffinitäten und besitzt keine eigene Boolean- oder Date/Time-Storage-Class.

Beispielcode aus der SQL Schulung:

-- PostgreSQL-orientiertes Beispiel:
CREATE TABLE rechnung (
  id        INTEGER PRIMARY KEY,
  betrag    NUMERIC(10,2) NOT NULL,
  faellig   DATE          NOT NULL,
  bezahlt   BOOLEAN       NOT NULL DEFAULT FALSE
);

In Systemen mit exaktem DECIMAL/NUMERIC-Typ eignet sich NUMERIC(10,2) für Dezimalbeträge. SQLite besitzt hiervon abweichende Typsemantik. DEFAULT setzt den definierten Anfangswert.

Wir beginnen mit Projektion (Spaltenauswahl) und Selektion (Zeilenfilter). In der SQL Schulung achten wir auf explizite Spaltenlisten statt SELECT *, um Stabilität und Performance zu fördern.

Beispielcode aus der SQL Schulung:

SELECT id, name
FROM teilnehmer
WHERE name LIKE 'A%';

Nur benötigte Spalten abfragen. LIKE mit Präfixfilter liefert Namen, die mit A beginnen.

WHERE reduziert die Ergebnismenge, ORDER BY legt die Reihenfolge fest, LIMIT beschränkt die Anzahl Zeilen. Wir formulieren klare Bedingungen und definieren deterministische Sortierungen.

Beispielcode aus der SQL Schulung:

SELECT kurs, datum
FROM buchung
WHERE datum >= CURRENT_DATE
ORDER BY datum ASC
LIMIT 10;

Kommende Buchungen, aufsteigend sortiert, auf 10 Einträge begrenzt — nützlich für Übersichtslisten.

DISTINCT entfernt Duplikate auf Zeilenebene. In der SQL Schulung nutzen wir es gezielt, prüfen aber zuerst die Datenmodellierung und Joins, um unbeabsichtigte Duplikate zu vermeiden.

Beispielcode aus der SQL Schulung:

SELECT DISTINCT kurs
FROM buchung
ORDER BY kurs;

Liefert jeden Kursnamen genau einmal. Vorzugsweise Ursachen für Duplikate analysieren (Daten, Join-Logik).

INNER JOIN liefert nur passende Zeilen beider Tabellen. In der SQL Schulung benennen wir Join-Bedingungen explizit und achten auf eindeutige Aliase bei mehrfachen Joins.

Beispielcode aus der SQL Schulung:

SELECT b.id, t.name, b.kurs, b.datum
FROM buchung b
JOIN teilnehmer t ON t.id = b.teilnehmer_id
WHERE b.datum >= CURRENT_DATE;

Nur Buchungen mit vorhandenem Teilnehmer werden gezeigt; Aliase b/t halten das Statement übersichtlich.

LEFT JOIN liefert alle Zeilen der linken Tabelle, auch ohne passende Rechte. RIGHT JOIN analog für die rechte Seite. In der SQL Schulung nutzen wir LEFT JOIN häufig für Berichte mit ‚fehlenden‘ Zuordnungen.

Beispielcode aus der SQL Schulung:

SELECT k.titel, b.id AS buchung_id
FROM kurs k
LEFT JOIN buchung b ON b.kurs = k.titel
ORDER BY k.titel;

Kurse ohne Buchung erscheinen mit NULL in buchung_id — hilfreich für Vollständigkeitsprüfungen.

COUNT/AVG/SUM/MIN/MAX verdichten Daten. GROUP BY bildet Gruppen, HAVING filtert auf Gruppenebene. In der SQL Schulung trennen wir bewusst WHERE (vor Gruppierung) und HAVING (nach Gruppierung).

Beispielcode aus der SQL Schulung:

SELECT kurs, COUNT(*) AS anzahl
FROM buchung
GROUP BY kurs
HAVING COUNT(*) >= 5
ORDER BY anzahl DESC;

Zeigt gut gebuchte Kurse ab fünf Anmeldungen. WHERE wäre hier falsch, wenn es um Gruppenbedingungen geht.

INSERT fügt Zeilen ein, UPDATE ändert Werte, DELETE entfernt Zeilen. In der SQL Schulung arbeiten wir mit klaren WHERE-Bedingungen und testen Updates/Deletes zunächst in einer Transaktion oder per SELECT-Vorschau.

Beispielcode aus der SQL Schulung:

-- INSERT
INSERT INTO teilnehmer (name, email)
VALUES ('Anna', 'anna@example.org');

-- UPDATE (nur offene Rechnungen)
UPDATE rechnung
SET bezahlt = TRUE
WHERE faellig < CURRENT_DATE
  AND bezahlt = FALSE;

-- DELETE: Stichtag als gebundener Parameter, da Datumsarithmetik DB-spezifisch ist.
DELETE FROM buchung
WHERE datum < :stichtag;

Selektive Bedingungen vermeiden unbeabsichtigte Massenänderungen. Vorher/Nachher prüfen.

NULL steht für ‚unbekannt/fehlt‘. Vergleiche mit NULL ergeben UNKNOWN. In der SQL Schulung verwenden wir IS NULL/IS NOT NULL und COALESCE für Standardwerte. Wir vermeiden zweideutige Auswertungen in Bedingungen.

Beispielcode aus der SQL Schulung:

SELECT COALESCE(email, 'keine E-Mail hinterlegt') AS kontakt
FROM teilnehmer
WHERE email IS NULL;

COALESCE ersetzt NULL. WHERE ... IS NULL filtert gezielt fehlende Werte.

Constraints prüfen Regeln auf Datenbankebene. In der SQL Schulung setzen wir NOT NULL, UNIQUE und CHECK ein, um valide Zustände zu erzwingen, unabhängig von der Anwendungsschicht.

Beispielcode aus der SQL Schulung:

CREATE TABLE kurs_termin (
  id     INTEGER PRIMARY KEY,
  kurs   TEXT NOT NULL,
  datum  DATE NOT NULL,
  preis  NUMERIC(10,2) NOT NULL CHECK (preis >= 0),
  UNIQUE (kurs, datum)
);

Doppeltermine werden verhindert; negative Preise sind unzulässig — Qualität wird am Ursprung gesichert.

UNION/UNION ALL vereinigt Ergebnismengen, INTERSECT bildet Schnittmengen, EXCEPT bildet Differenzen. In der SQL Schulung achten wir auf kompatible Spaltenanzahl und -typen.

Beispielcode aus der SQL Schulung:

(SELECT name FROM teilnehmer WHERE name LIKE 'A%')
UNION
(SELECT name FROM teilnehmer WHERE name LIKE 'B%')
ORDER BY name;

UNION entfernt Duplikate; UNION ALL behält sie und kann den zusätzlichen Schritt zur Duplikateliminierung vermeiden. Welcher Plan schneller ist, hängt von Datenbanksystem, Datenmenge und Ausführungsplan ab.

CASE erlaubt bedingte Ableitungen direkt in Abfragen. In der SQL Schulung nutzen wir CASE für Gruppierungen, Labels und Ausnahmen ohne nachgelagerte Verarbeitung.

Beispielcode aus der SQL Schulung:

SELECT name,
       CASE
         WHEN email LIKE '%.de' THEN 'DE'
         WHEN email LIKE '%.at' THEN 'AT'
         ELSE 'andere'
       END AS region
FROM teilnehmer;

Einfache Klassifikation aus vorhandenen Spaltenwerten, direkt in der Abfrage.

String- und Datumsfunktionen sind teilweise produktspezifisch. TRIM, LOWER und UPPER sind weit verbreitet; bei Datumsfunktionen muss der konkrete Dialekt geprüft werden. Das folgende date_trunc-Beispiel verwendet PostgreSQL.

Beispielcode aus der SQL Schulung:

-- PostgreSQL-Beispiel:
SELECT UPPER(TRIM(name)) AS name_norm,
       date_trunc('month', datum) AS monat
FROM buchung;

Das Beispiel vereinheitlicht Text und bildet Datumswerte in PostgreSQL auf Monatsgrenzen ab. SQLite und MySQL verwenden hierfür andere Funktionsmodelle.

Transaktionen bündeln Änderungen atomar. ACID (Atomicity, Consistency, Isolation, Durability) sichert Korrektheit. In der SQL Schulung nutzen wir BEGIN/COMMIT/ROLLBACK und testen Fehlerszenarien.

Beispielcode aus der SQL Schulung:

BEGIN;
  UPDATE rechnung SET bezahlt = TRUE WHERE id = 101;
  INSERT INTO zahlung (rechnung_id, betrag) VALUES (101, 450.00);
COMMIT; -- oder ROLLBACK bei Fehlern

Änderungen erfolgen ganz oder gar nicht. Inkonsistente Zwischenstände werden vermieden.

Isolation und Sperrverhalten sind produktspezifisch. In der SQL Schulung werden gemeinsame Konzepte wie konkurrierende Änderungen und Isolationsstufen erläutert; konkrete Sperrsyntax und Wirkung werden für das jeweilige Datenbanksystem geprüft.

Beispielcode aus der SQL Schulung:

-- Beispiel: explizite Sperre auf Zeile/Relation (DB-abhängig)
BEGIN;
  SELECT * FROM rechnung WHERE id = 101 FOR UPDATE;
  -- Bearbeitung ...
COMMIT;

SELECT ... FOR UPDATE sperrt in PostgreSQL und MySQL ausgewählte Zeilen gegen bestimmte konkurrierende Operationen. Die genaue Wirkung hängt von Datenbanksystem, Transaktion und Isolationskontext ab; SQLite verwendet ein anderes Sperrmodell.

Normalformen reduzieren Redundanz und Anomalien. In der SQL Schulung prüfen wir 1NF (atomare Werte), 2NF (vollständige Abhängigkeit vom Schlüssel) und 3NF (keine transitiven Abhängigkeiten).

Beispielcode aus der SQL Schulung:

-- Beispiel: Auslagerung mehrfach verwendeter Werte
CREATE TABLE format (
  id   INTEGER PRIMARY KEY,
  name TEXT UNIQUE NOT NULL
);

-- kurs.format_id statt kurs.format_text

Statt freien Text mehrfach zu speichern, verweisen wir auf eine Referenztabelle — konsistent und auswertbar.

Wir vergeben minimale Rechte per Rolle. In der SQL Schulung trennen wir Lese-/Schreibrechte und verhindern so unbeabsichtigte Änderungen in produktionsnahen Umgebungen.

Beispielcode aus der SQL Schulung:

-- (DB-abhängig, Beispiel PostgreSQL)
CREATE ROLE reporter NOINHERIT;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO reporter;

Leserolle erhält nur SELECT. Schreibrechte werden gesondert und fein granular vergeben.

Subqueries kapseln Teilabfragen. In der SQL Schulung nutzen wir skalare, korrelierte und IN/EXISTS-Varianten für klar strukturierte, wiederverwendbare Abfragen.

Beispielcode aus der SQL Schulung:

SELECT name
FROM teilnehmer t
WHERE EXISTS (
  SELECT 1 FROM buchung b
  WHERE b.teilnehmer_id = t.id AND b.kurs = 'SQL Grundlagen'
);

EXISTS prüft effizient, ob mindestens eine passende Buchung existiert.

Common Table Expressions (WITH) zerlegen komplexe Abfragen in benannte Schritte. In der SQL Schulung fördern wir damit Wartbarkeit und Testbarkeit.

Beispielcode aus der SQL Schulung:

WITH kommende AS (
  SELECT * FROM buchung WHERE datum >= CURRENT_DATE
)
SELECT kurs, COUNT(*) FROM kommende GROUP BY kurs;

Die Teilmenge wird benannt und wiederverwendet. Komplexe Logik bleibt nachvollziehbar.

Views speichern wiederkehrende Abfrage-Logik unter einem Namen. In der SQL Schulung verwenden wir sie als stabile Berichts- oder Integrationsschnittstellen.

Beispielcode aus der SQL Schulung:

CREATE VIEW v_buchungen_heute AS
SELECT b.*, t.name
FROM buchung b
JOIN teilnehmer t ON t.id = b.teilnehmer_id
WHERE b.datum = CURRENT_DATE;

Konsistente Sicht für heutige Buchungen, ohne die Originaltabellen direkt zu belasten.

Indizes können Suchen, Joins und Sortierungen beschleunigen, wenn Abfrage, Datenverteilung und Indexstruktur zusammenpassen. Sie benötigen Speicher und erzeugen zusätzlichen Aufwand bei Schreiboperationen. Deshalb werden Abfragepläne und reale Zugriffsmuster geprüft.

Beispielcode aus der SQL Schulung:

CREATE INDEX idx_buchung_datum ON buchung(datum);
CREATE INDEX idx_buchung_teilnehmer ON buchung(teilnehmer_id, datum);

Einzel- und Mehrspaltenindex unterstützen typische Filter und Join-Pfade effizient.

Werkzeuge zur Plananalyse sind produktspezifisch. PostgreSQL und MySQL bieten EXPLAIN-Varianten; SQLite bietet unter anderem EXPLAIN QUERY PLAN. Kostenangaben, Knotennamen und Messmöglichkeiten dürfen nicht ungeprüft zwischen Produkten übertragen werden.

Beispielcode aus der SQL Schulung:

-- PostgreSQL-Beispiel:
EXPLAIN ANALYZE
SELECT b.*
FROM buchung b
WHERE b.datum >= CURRENT_DATE;

Der Plan zeigt den vom Optimizer gewählten Zugriffspfad. Eine nicht erfolgte Indexnutzung kann unterschiedliche Ursachen haben, etwa Kostenabschätzung, Selektivität, Datenmenge oder Indexdesign.

Window Functions (OVER/PARTITION BY/ORDER BY) berechnen laufende Werte ohne Gruppierung. In der SQL Schulung erstellen wir Rankings, gleitende Durchschnitte und kumulative Summen.

Beispielcode aus der SQL Schulung:

SELECT kurs, datum,
       COUNT(*) OVER (PARTITION BY kurs ORDER BY datum
                      ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS kumulativ
FROM buchung;

Kumulierte Buchungen je Kurs, ohne Zeilen zu verdichten — wichtig für Zeitreihenberichte.

SQL operiert auf Mengen, nicht auf Einzelzeilen-Schleifen. In der SQL Schulung formulieren wir Abfragen so, dass die Datenbank Optimierungen ausführen kann, statt Daten in die Anwendung zu ziehen.

Beispielcode aus der SQL Schulung:

-- Statt pro Teilnehmer zu zählen, in einer Abfrage gruppieren:
SELECT teilnehmer_id, COUNT(*) FROM buchung GROUP BY teilnehmer_id;

Die Aggregation erfolgt datenbankseitig — weniger Netzverkehr, bessere Optimierung.

READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ und SERIALIZABLE dienen als Vergleichsrahmen; die tatsächlich unterstützte Semantik wird je Datenbanksystem geprüft. PostgreSQL behandelt READ UNCOMMITTED wie READ COMMITTED, während andere Produkte die Stufen anders umsetzen können.

Beispielcode aus der SQL Schulung:

-- DB-abhängig, Beispiel PostgreSQL:
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

Stärkere Isolation kann bestimmte Anomalien verhindern, beeinflusst aber je nach Datenbanksystem Parallelität, Sperren und Konfliktverhalten. Die konkrete Wirkung wird produktspezifisch geprüft.

Wir besprechen logische und physische Backups, Wiederherstellungsziele (RPO/RTO) und testen Wiederherstellung in einer separaten Umgebung. Ziel ist belastbare Betriebsfähigkeit.

Beispielcode aus der SQL Schulung:

-- Werkzeugspezifisch (pg_dump/mysqldump etc.); im Kurs erläutern wir Abläufe und Prüfschritte.

Technikspezifische Befehle variieren. Entscheidend ist ein dokumentierter, getesteter Prozess.

Views können sensible Spalten ausblenden und nur geprüfte Daten zeigen. In der SQL Schulung kombinieren wir Views mit Rollenrechten für Least Privilege.

Beispielcode aus der SQL Schulung:

CREATE VIEW v_teilnehmer_public AS
SELECT id, name
FROM teilnehmer;

-- Rolle erhält nur Zugriff auf die View, nicht auf die Basistabelle.

Berichte arbeiten auf der View; sensible Spalten (z. B. E-Mail) bleiben geschützt.

Wir importieren/entladen Daten kontrolliert (z. B. CSV), berücksichtigen Zeichensatz/Trennzeichen und validieren Ergebnisse mit Stichproben und Constraints.

Beispielcode aus der SQL Schulung:

-- DB-abhängig, Beispiel PostgreSQL COPY:
-- COPY teilnehmer(name,email) FROM '/pfad/teilnehmer.csv' CSV HEADER;

Nach Import prüfen wir Anzahl, NULL-Quoten und Stichproben, bevor Daten produktiv genutzt werden.

Trigger führen Logik auf DML-Ereignisse aus. In der SQL Schulung nutzen wir sie sparsam für Querschnittsaufgaben (Audit, technische Konsistenz), nicht für komplexe Fachlogik.

Beispielcode aus der SQL Schulung:

-- DB-abhängig; im Kurs zeigen wir ein Audit-Beispiel für Änderungen an rechnung.

Trigger sind mächtig, erhöhen aber Kopplung. Einsatz begründen und dokumentieren.

Prozeduren/Funktionen kapseln servernahe Logik. In der SQL Schulung bewerten wir Nutzen (Nähe zu Daten, Performance) gegenüber Nachteilen (Portabilität, Deployment). Einsatz gezielt und testbar gestalten.

Beispielcode aus der SQL Schulung:

-- DB-abhängig (PL/pgSQL, T-SQL, PL/SQL); wir zeigen Muster für Validierung und Batch-Verarbeitung.

Prozeduren sollten deterministisch und gut testbar sein. Schnittstellen klar dokumentieren.

Wir nutzen ausschließlich parametrisierte Abfragen/Prepared Statements. In der SQL Schulung zeigen wir, warum String-Konkatenation für SQL strikt zu vermeiden ist.

Beispielcode aus der SQL Schulung:

-- Parameterbindung wird in der Anwendung gesetzt (Framework/Driver). -- Das Statement enthält Platzhalter statt zusammengebauter Strings.

Die Datenbank unterscheidet klar zwischen Code und Daten — Angriffsfläche wird minimiert.

Partitionierung teilt große Tabellen in Segmente (z. B. nach Datum). In der SQL Schulung zeigen wir bessere Wartung, gezielte Abfragen und vereinfachte Archivierung.

Beispielcode aus der SQL Schulung:

-- DB-abhängig; Beispiel: Range-Partitionen nach Datum für buchung.

Partition Pruning kann die zu prüfenden Partitionen reduzieren, wenn Abfrageprädikate und Partitionierung zusammenpassen. Ein Performancegewinn ist nicht automatisch garantiert; Wartung und Archivierung können unabhängig davon profitieren.

Materialisierte Sichten sind produktspezifische Datenbankobjekte. PostgreSQL stellt mit Materialized Views persistierte Abfrageergebnisse bereit, die explizit aktualisiert werden können. Andere Datenbanksysteme besitzen abweichende Funktionen oder Konzepte.

Beispielcode aus der SQL Schulung:

-- DB-abhängig; Beispiel PostgreSQL:
-- CREATE MATERIALIZED VIEW mv_report AS SELECT ...;
-- REFRESH MATERIALIZED VIEW mv_report;

Eine materialisierte Sicht kann wiederholte Berechnungen reduzieren. Tatsächliche Laufzeit, Speicherbedarf und Aktualität hängen von Abfrage, Datenmenge, Indizes und Refresh-Strategie ab.

Performance wird anhand realer Abfragepläne und repräsentativer Daten beurteilt. Sinnvoll sind unter anderem passende Indizes, begrenzte Ergebnismengen und indexfreundliche Prädikate; pauschale Regeln ohne Produkt-, Daten- und Indexkontext sind zu vermeiden.

Beispielcode aus der SQL Schulung:

-- Parameterisiertes Range-Prädikat:
SELECT *
FROM buchung
WHERE datum >= :stichtag;

Ein einfaches Range-Prädikat kann indexfreundlich sein. Funktionen auf einer Spalte schließen Indexnutzung jedoch nicht grundsätzlich aus; Expression-Indizes beziehungsweise funktionale Indizes und Optimizer-Verhalten sind produktspezifisch.

Denormalisierung kann Reporting vereinfachen oder Performance verbessern. In der SQL Schulung setzen wir sie gezielt ein und sichern Konsistenz über ETL/Materialization oder Trigger.

Beispielcode aus der SQL Schulung:

-- Beispiel: voraggregierte Tabelle für Dashboard-KPIs (nächtlicher ETL-Job).

Trade-off zwischen Schreib-/Speicheraufwand und schneller Lese-Performance wird transparent abgewogen.

Wir speichern Gültigkeitszeiträume (valid_from/valid_to) oder nutzen Systemversionierung (DB-abhängig). In der SQL Schulung zeigen wir Punkte-/Periodenabfragen und Überlappungsprüfungen.

Beispielcode aus der SQL Schulung:

CREATE TABLE preisregel (
  id         INTEGER PRIMARY KEY,
  kurs       TEXT NOT NULL,
  betrag     NUMERIC(10,2) NOT NULL,
  valid_from DATE NOT NULL,
  valid_to   DATE
);

Abfragen berücksichtigen das Datum der Gültigkeit; Überschneidungen werden per CHECK/Queries verhindert.

JSON-Unterstützung ist produktspezifisch. PostgreSQL bietet json und jsonb, SQLite stellt JSON-Funktionen innerhalb seines eigenen Typmodells bereit, und weitere Systeme besitzen wiederum eigene Typen, Funktionen und Indexmöglichkeiten. Relationale Kerndaten und JSON-Anteile werden deshalb bewusst getrennt modelliert.

Beispielcode aus der SQL Schulung:

-- DB-abhängig; Beispiel PostgreSQL:
-- SELECT details->>'unternehmen' AS firma FROM teilnehmer_extras;

JSON ergänzt, ersetzt aber nicht das relationale Modell. Abfragen und Indizes werden gezielt geplant.

Wir minimieren gespeicherte personenbezogene Daten, pseudonymisieren wo möglich und begrenzen Zugriffe über Rollen/Views. Audit- und Löschkonzepte werden fachlich abgestimmt.

Beispielcode aus der SQL Schulung:

-- Beispiel: Trennung Stammdaten vs. Reporting-View ohne E-Mail

Nur die Daten speichern/zeigen, die für den Zweck erforderlich sind (Datenminimierung).

Für Integrationen nutzen wir reproduzierbare Ladeprozesse (Staging → Validierung → Produktion). In der SQL Schulung definieren wir Idempotenz, Protokollierung und Fehlerroutinen.

Beispielcode aus der SQL Schulung:

-- Typisches, produktabhängiges Muster:
-- 1) Daten in Staging laden (PostgreSQL z. B. mit COPY)
-- 2) Daten fachlich und technisch validieren
-- 3) Produktspezifischen Merge/Upsert in die Zieltabelle ausführen

Klare Phasen und Protokolle machen Datenbewegungen nachvollziehbar und auditierbar.

Upsert- und Merge-Syntax ist produktspezifisch. PostgreSQL und SQLite bieten ON-CONFLICT-Varianten; MySQL verwendet INSERT ... ON DUPLICATE KEY UPDATE. MERGE ist ebenfalls nicht in allen Produkten syntaktisch oder semantisch identisch.

Beispielcode aus der SQL Schulung:

-- PostgreSQL:
INSERT INTO teilnehmer (id, name, email)
VALUES (1, 'Anna', 'anna@example.org')
ON CONFLICT (id) DO UPDATE SET name = EXCLUDED.name, email = EXCLUDED.email;

Ein atomarer produktspezifischer Upsert kann anwendungsseitige Check-then-Insert-Rennfenster vermeiden. Eindeutige Constraints, Konfliktziel und die konkrete Produktsemantik bleiben entscheidend.

Wir trennen Anwendungs-, Staging- und Reporting-Schemas und vergeben Rechte rollenbasiert. In der SQL Schulung erleichtert das Deployments und kontrolliert Zugriffspfade.

Beispielcode aus der SQL Schulung:

-- Beispiel:
-- SCHEMA app, staging, rpt
-- Rollen: app_rw, rpt_ro etc.

Klare Zuständigkeiten pro Schema/Role verhindern Wildwuchs und erleichtern Governance.

Wir nutzen Beispieldatasets, deterministische Fixtures und vergleichen erwartete mit tatsächlichen Ergebnissen. Abfragen werden versionsverwaltet und Review-pflichtig gemacht.

Beispielcode aus der SQL Schulung:

-- Golden-Master-Ansatz: Ergebnis in Referenztabelle ablegen und regelmäßig vergleichen.

Stabile Tests sichern Berichte und ETL-Schritte gegen unbeabsichtigte Änderungen ab.