Was ist SQL? Datenbanken, Tabellen, Abfragen und sichere Änderungen erklärt

Tabellen geben gleichartigen Datensätzen eine feste Struktur

Eine relationale Datenbank organisiert Daten in Tabellen. Eine Kundentabelle kann beispielsweise Namen und Kundennummern enthalten, während eine Rechnungstabelle Rechnungsdatum, Betrag und Zahlungsstatus speichert. Jede Tabelle bündelt Datensätze, die fachlich dieselbe Art von Objekt beschreiben.

Eine Zeile steht für einen einzelnen Datensatz, etwa einen bestimmten Kunden. Die Spalten beschreiben dessen Eigenschaften, beispielsweise Kundennummer und Name. Spalten besitzen Namen und Datentypen. Ein Datentyp legt grundsätzlich fest, ob eine Spalte etwa ganze Zahlen, Text, Datumswerte oder Dezimalzahlen aufnimmt. Zusätzliche Regeln können Pflichtwerte, zulässige Werte oder Beziehungen zu anderen Tabellen absichern.

In einer Produkttabelle bildet daher nicht jede Zelle einen beliebigen Ablageplatz. Alle Zeilen folgen derselben Spaltenstruktur: Eine Zeile könnte Produkt 4711 beschreiben, die Spalte preis enthält dessen Preis und die Spalte status beispielsweise den Wert aktiv. Dieses regelmäßige Modell ermöglicht gezielte Abfragen über große Datenbestände.

Datenbank, Datenbankmanagementsystem und SQL sind nicht dasselbe

Die Datenbank bezeichnet vereinfacht den organisierten Datenbestand. Das Datenbankmanagementsystem, kurz DBMS, verwaltet unter anderem Speicherung, Abfragen, Benutzerrechte, gleichzeitige Zugriffe und Transaktionen. SQL ist die Sprache, mit der Anwendungen oder Verwaltungswerkzeuge viele dieser Aufgaben beim DBMS anfordern.

Bekannte SQL-Systeme sind MySQL, MariaDB, PostgreSQL, SQLite, Microsoft SQL Server und Oracle Database. SQLite wird häufig direkt in eine Anwendung eingebettet, während die anderen genannten Systeme typischerweise als Server oder verwalteter Datenbankdienst betrieben werden. Die gemeinsame SQL-Basis bedeutet jedoch nicht, dass sämtliche Befehle, Datentypen und Funktionen austauschbar sind.

SQL ist vor allem eine deklarative, mengenorientierte Datenbanksprache. Eine Anweisung beschreibt, welches Ergebnis benötigt wird; das DBMS entscheidet anhand seiner Daten, Indizes und Ausführungsplanung, wie es dieses Ergebnis ermittelt. Allgemeine Programmiersprachen wie Java, Python oder C übernehmen dagegen typischerweise Anwendungslogik, Benutzeroberflächen und Kommunikation mit anderen Diensten. SQL-Standards und Herstellerdialekte können zwar Routinen, Variablen oder Kontrollstrukturen bieten, doch daraus wird SQL nicht zur universellen Sprache für komplette Anwendungen.

SELECT beschreibt, welche Daten das Ergebnis enthalten soll

SELECT produktname, preis
FROM produkte
WHERE status = 'aktiv'
ORDER BY produktname;

Diese Abfrage fordert die Spalten produktname und preis aus der Tabelle produkte an. WHERE lässt nur aktive Produkte durch, ORDER BY sortiert das Ergebnis nach dem Produktnamen. Die Großschreibung der Schlüsselwörter verbessert die Lesbarkeit, ist bei den üblichen Systemen aber keine allgemeine technische Pflicht.

Explizit genannte Spalten sind häufig verständlicher als SELECT *. Die Anwendung erhält nur die vorgesehenen Daten, und spätere Tabellenerweiterungen verändern das Abfrageergebnis nicht unbemerkt. Bei einem JOIN verhindert die Spaltenliste außerdem doppelte oder uneindeutige Ausgabespalten.

Schlüssel verbinden Tabellen, ohne Daten unnötig zu kopieren

Ein Primärschlüssel identifiziert jede Tabellenzeile eindeutig und darf keinen NULL-Wert enthalten. Eine Kundennummer eignet sich deshalb als technische Referenz besser als ein Name: Zwei Kunden können gleich heißen, während jeder Primärschlüssel nur einmal vorkommt.

Ein Fremdschlüssel verweist aus einer Tabelle auf einen gültigen Schlüsselwert einer anderen Tabelle. Die Rechnung speichert beispielsweise die kunden_id, aber nicht in jeder Zeile erneut den Kundennamen und sämtliche Kontaktdaten. Das DBMS kann dadurch verhindern, dass eine Rechnung auf einen nicht vorhandenen Kunden verweist. Ein Fremdschlüssel ist eine Integritätsregel und darf nicht pauschal mit einem Index gleichgesetzt werden.

Ein JOIN führt diese fachlich getrennten Informationen für ein Abfrageergebnis wieder zusammen. Die Tabellen werden dabei nicht dauerhaft zu einer neuen Tabelle verschmolzen. Das DBMS bildet Ergebniszeilen, indem es etwa rechnungen.kunden_id mit kunden.kunden_id vergleicht. Ein INNER JOIN liefert nur passende Zeilenpaare. Ein LEFT JOIN kann zusätzlich Zeilen der linken Tabelle erhalten, für die rechts kein Treffer existiert.

Ein Index ähnelt dem Register eines Fachbuchs: Das DBMS kann passende Fundstellen gezielter erreichen, statt jede Zeile vollständig zu prüfen. Indizes können Bedingungen, Sortierungen und JOINs beschleunigen. Sie benötigen jedoch Speicher und verursachen zusätzlichen Aufwand bei INSERT, UPDATE und DELETE. Ob ein Index tatsächlich verwendet wird, entscheidet der Abfrageplaner anhand der Abfrage und der Datenverteilung.

Eine Transaktion bündelt zusammengehörige Operationen zu einer logischen Einheit. Bei Erfolg bestätigt COMMIT die Änderungen. Bei einem Fehler verwirft ROLLBACK die noch nicht bestätigten Änderungen. Autocommit, implizite Bestätigungen und die Rücksetzbarkeit bestimmter Strukturänderungen hängen vom Datenbanksystem, der Speichertechnik und dem verwendeten Werkzeug ab.

1. Kunden- und Rechnungstabelle anlegen

Kompatibilität vor dem Ausführen: Die FOREIGN KEY-Definition legt die Beziehung im Schema fest. Bei SQLite muss die Fremdschlüsselunterstützung jedoch in der verwendeten Bibliothek vorhanden und für jede Verbindung ausdrücklich aktiviert sein. Prüfen Sie PRAGMA foreign_keys und setzen Sie den Wert vor der Nutzung auf ON, bevor Sie sich auf die Zurückweisung ungültiger Verweise verlassen.

CREATE TABLE kunden (
    kunden_id INTEGER PRIMARY KEY,
    name VARCHAR(120) NOT NULL
);

CREATE TABLE rechnungen (
    rechnung_id INTEGER PRIMARY KEY,
    kunden_id INTEGER NOT NULL,
    rechnungsdatum DATE NOT NULL,
    betrag DECIMAL(10,2) NOT NULL,
    status VARCHAR(20) NOT NULL,
    FOREIGN KEY (kunden_id) REFERENCES kunden(kunden_id)
);

In kunden identifiziert kunden_id jede Zeile eindeutig. In rechnungen übernimmt rechnung_id dieselbe Aufgabe für Rechnungen. Die dort gespeicherte kunden_id ist zugleich ein Fremdschlüssel: Eine nicht leere Kunden-ID muss bei aktiv durchgesetzter Fremdschlüsselprüfung zu einem vorhandenen Kunden passen.

Der Kundenname wird nicht in jeder Rechnung wiederholt. Dadurch gibt es einen zentralen Änderungsort, falls sich der Name korrigieren lässt, und keine widersprüchlichen Schreibweisen über zahlreiche Rechnungszeilen hinweg. Die Beziehung bleibt dennoch eindeutig, weil beide Tabellen dieselbe Kunden-ID verwenden. Die konkreten Größen, Literalschreibweisen und Konvertierungsregeln der Datentypen müssen Sie im Zielsystem prüfen.

2. Einen Kunden und seine Rechnungen speichern

INSERT INTO kunden (kunden_id, name)
VALUES (101, 'Beispielhandel Nord');

INSERT INTO rechnungen
    (rechnung_id, kunden_id, rechnungsdatum, betrag, status)
VALUES
    (2001, 101, '2026-07-10', 149.90, 'offen'),
    (2002, 101, '2026-06-15', 79.50, 'bezahlt');

INSERT erzeugt neue Zeilen. Die expliziten Spaltenlisten zeigen, welcher Wert in welche Spalte gehört. Beide Rechnungen verweisen über den Wert 101 auf denselben Kunden. Würde die angegebene Kunden-ID nicht existieren, muss eine aktiv durchgesetzte Fremdschlüsselregel das Einfügen zurückweisen. Bei SQLite gilt dies nur unter den zuvor genannten Voraussetzungen.

3. Offene Rechnungen mit WHERE auswählen

SELECT rechnung_id, kunden_id, rechnungsdatum, betrag
FROM rechnungen
WHERE status = 'offen'
ORDER BY rechnungsdatum DESC, rechnung_id DESC;

WHERE prüft den Status jeder infrage kommenden Zeile und lässt nur offene Rechnungen in das Ergebnis. ORDER BY rechnungsdatum DESC ordnet neuere Datumswerte vor älteren; rechnung_id DESC legt zusätzlich die Reihenfolge bei gleichem Rechnungsdatum fest. Ohne ORDER BY kann eine Ausgabe zufällig stabil wirken, ihre Reihenfolge ist jedoch nicht verlässlich festgelegt.

4. Kundenname und Rechnungsdaten mit JOIN zusammenführen

SELECT
    k.name,
    r.rechnung_id,
    r.rechnungsdatum,
    r.betrag,
    r.status
FROM kunden AS k
INNER JOIN rechnungen AS r
    ON r.kunden_id = k.kunden_id
WHERE r.status = 'offen'
ORDER BY r.rechnungsdatum DESC, r.rechnung_id DESC;

Die Aliase k und r verkürzen die Tabellennamen. Entscheidend ist die ON-Bedingung: Eine Rechnungszeile wird mit der Kundenzeile kombiniert, deren Kunden-ID übereinstimmt. Der zusätzliche WHERE-Filter beschränkt das bereits fachlich verknüpfte Ergebnis auf offene Rechnungen.

Fehlt eine korrekte Verknüpfungsbedingung, können unpassende Zeilenkombinationen und vervielfachte Ergebnisse entstehen. Prüfen Sie deshalb bei einem JOIN zuerst die Beziehung der Schlüssel und anschließend, ob die Ergebniszahl fachlich plausibel ist. Das Datenbankmodell liefert die Beziehung; die Abfrage muss sie korrekt verwenden.

5. Rechnungszahl und Gesamtbetrag je Kunde auswerten

SELECT
    k.kunden_id,
    k.name,
    COUNT(r.rechnung_id) AS anzahl_rechnungen,
    SUM(r.betrag) AS gesamtbetrag
FROM kunden AS k
INNER JOIN rechnungen AS r
    ON r.kunden_id = k.kunden_id
GROUP BY k.kunden_id, k.name;

GROUP BY bildet für jede Kombination aus Kunden-ID und Name eine Gruppe. COUNT zählt die zugehörigen Rechnungen, SUM addiert deren Beträge. Ein vorher gesetztes WHERE könnte die Eingabezeilen beispielsweise auf offene Rechnungen begrenzen. Die Gruppierung selbst entscheidet dagegen, welche Zeilen gemeinsam ausgewertet werden.

6. Zusammengehörige Einfügungen als Transaktion behandeln

Transaktionssyntax anpassen: Der folgende Block verwendet BEGIN; als PostgreSQL-kompatible Referenzschreibweise. Microsoft SQL Server startet eine explizite Transaktion mit BEGIN TRANSACTION oder BEGIN TRAN. In Oracle beginnt eine gewöhnliche Transaktion mit der ersten ausführbaren SQL-Anweisung; dort gibt es keinen entsprechenden BEGIN;-Startbefehl. COMMIT und ROLLBACK beenden die Transaktion.

BEGIN;

INSERT INTO kunden (kunden_id, name)
VALUES (102, 'Musterbüro West');

INSERT INTO rechnungen
    (rechnung_id, kunden_id, rechnungsdatum, betrag, status)
VALUES
    (2003, 102, '2026-07-28', 320.00, 'offen');

COMMIT;

Die beiden Einfügungen bilden fachlich einen Vorgang: Ein neuer Kunde soll zusammen mit seiner ersten Rechnung entstehen. Sind beide Schritte erfolgreich und geprüft, bestätigt COMMIT die Transaktion. Scheitert die Rechnung, führen Sie statt COMMIT ein ROLLBACK aus. Dadurch bleibt kein unvollständiger Vorgang mit einem isoliert angelegten Kunden zurück.

Prüfen Sie vor produktiver Nutzung, wie Ihr DBMS und das verwendete Client-Werkzeug Transaktionen starten, Autocommit behandeln und Fehlerzustände zurücksetzen. Verlassen Sie sich insbesondere bei CREATE und ALTER nicht auf eine universelle Rollback-Garantie.

7. Eine Statusänderung vor COMMIT kontrollieren

Vor einem UPDATE oder DELETE sollten Sie nicht nur die Syntax prüfen, sondern vor allem die Zielmenge. Eine belastbare Arbeitsfolge lautet: dieselbe WHERE-Bedingung zuerst mit SELECT testen, eine geeignete Transaktion starten, die Änderung ausführen, die Zahl und den Inhalt der betroffenen Zeilen kontrollieren und erst danach bestätigen.

Der folgende Prüfblock nutzt erneut BEGIN; als Referenzschreibweise. Passen Sie den Transaktionsstart für SQL Server an und lassen Sie diesen Startbefehl in Oracle weg, bevor Sie das Beispiel ausführen.

SELECT rechnung_id, status
FROM rechnungen
WHERE rechnung_id = 2001;

BEGIN;

UPDATE rechnungen
SET status = 'bezahlt'
WHERE rechnung_id = 2001;

SELECT rechnung_id, status
FROM rechnungen
WHERE rechnung_id = 2001;

COMMIT;

Der Primärschlüssel grenzt die Änderung auf eine eindeutig identifizierte Rechnung ein. Kontrollieren Sie zusätzlich die vom Client gemeldete Zahl betroffener Zeilen. Sind unerwartet null oder mehrere Zeilen betroffen, bestätigen Sie die Transaktion nicht, sondern prüfen Bedingung und Datenbestand.

-- Warnbeispiel: nicht auf produktiven Daten ausführen
UPDATE rechnungen
SET status = 'bezahlt';

Ohne WHERE ändert diese Anweisung den Status jeder Rechnungszeile. Entsprechend entfernt DELETE FROM rechnungen ohne Filter sämtliche Zeilen der Tabelle. Beide Anweisungen können syntaktisch vollkommen gültig sein und dennoch fachlich katastrophal wirken.

Ein Backup ersetzt diese Prüflogik nicht. Es ermöglicht die Wiederherstellung eines früheren Datenstands, während eine Transaktion die Vollständigkeit des aktuell ausgeführten Vorgangs schützt. Eine Rücksicherung kann Zeit kosten, den Betrieb unterbrechen und neuere korrekte Änderungen überschreiben. Halten Sie deshalb ein aktuelles, nach Herstellerverfahren erstelltes und tatsächlich wiederherstellbares Backup bereit, nutzen Sie aber trotzdem präzise Filter, Transaktionen und Ergebniskontrollen.

SQL-Injection entsteht, wenn Eingaben die Abfragestruktur verändern können

Eine SQL-Injection kann entstehen, wenn Anwendungscode nicht vertrauenswürdige Eingaben per Zeichenkettenverkettung direkt in eine SQL-Anweisung einbaut. Ein Angreifer könnte dadurch versuchen, die beabsichtigte Struktur der Abfrage zu verändern. Mögliche Folgen reichen vom unberechtigten Lesen bis zum Verändern oder Löschen von Daten.

Die zentrale technische Gegenmaßnahme sind parametrisierte Abfragen beziehungsweise Prepared Statements. Dabei wird die SQL-Struktur getrennt von den Eingabewerten definiert. Das Datenbanksystem behandelt den übergebenen Wert als Datenwert und nicht als nachträglich eingefügten SQL-Code. Eingabevalidierung bleibt sinnvoll, ersetzt diese Trennung aber nicht.

Vergeben Sie der Anwendung zusätzlich nur die benötigten Datenbankrechte. Ein Konto, das lediglich bestimmte Datensätze lesen muss, benötigt keine Berechtigung zum Löschen von Tabellen oder Ändern von Strukturen. Minimale Rechte begrenzen mögliche Folgen eines Fehlers oder Angriffs, beheben jedoch keine unsichere Abfragekonstruktion.

Typische SQL-Fehler systematisch eingrenzen

• Falsche WHERE-Bedingung: Prüfen Sie die Zielzeilen zuerst mit SELECT. Eine syntaktisch gültige Bedingung kann einen falschen Status, Zeitraum oder Schlüssel verwenden und dadurch fachlich falsche Daten treffen.
• Fehlendes WHERE: Stoppen Sie die Ausführung, wenn ein UPDATE oder DELETE nicht ausdrücklich den gesamten Tabellenbestand erfassen soll. Nutzen Sie nach Möglichkeit Transaktionen und prüfen Sie die Zahl betroffener Zeilen vor COMMIT.
• Fehlendes oder ungeprüftes Backup: Erstellen Sie vor riskanten Daten- und Strukturänderungen eine Sicherung nach dem Verfahren Ihres Systems. Testen Sie die Wiederherstellung; eine vorhandene Datei ist noch kein belastbarer Wiederherstellungsnachweis.
• Syntaxfehler: Lesen Sie die vollständige Fehlermeldung und prüfen Sie die angegebene Position, Kommas, Klammern, Anführungszeichen, Schlüsselwörter und Spaltennamen. Klären Sie außerdem, ob das Beispiel zum SQL-Dialekt Ihres Systems gehört.
• Zeichensatz- oder Kollationsprobleme: Prüfen Sie Datenbank, Tabellen, Client-Verbindung, Importdatei und Anwendung gemeinsam. Encoding und Kollation beeinflussen, welche Zeichen gespeichert werden können und wie Text verglichen oder sortiert wird.
• Fehlende Berechtigungen: Ermitteln Sie, ob konkret SELECT-, INSERT-, UPDATE-, DELETE– oder Strukturrechte fehlen. Vergeben Sie nicht pauschal eine Administratorrolle, wenn eine eng begrenzte Berechtigung genügt.
• Langsame Abfrage: Prüfen Sie Datenmenge, ausgewählte Spalten, WHERE– und JOIN-Bedingungen sowie den Ausführungsplan. Legen Sie einen Index erst an, wenn Messung und Plan einen sinnvollen Kandidaten erkennen lassen; zusätzliche Indizes erhöhen den Schreib- und Wartungsaufwand.

Was bedeutet SQL?

SQL bedeutet Structured Query Language. Die Sprache dient dazu, relationale Datenbanken abzufragen, Daten einzufügen oder zu ändern, Strukturen anzulegen und Verwaltungsaufgaben anzufordern.

Ist SQL eine Programmiersprache?

SQL ist eine deklarative Datenbanksprache und keine allgemeine Anwendungsprogrammiersprache wie Python oder Java. Standards und Herstellerdialekte können jedoch prozedurale Erweiterungen, Routinen und Kontrollstrukturen enthalten. Ein pauschales Nein wäre deshalb ebenso ungenau wie die Gleichsetzung mit einer universellen Programmiersprache.

Was ist eine Tabelle?

Eine Tabelle ist eine benannte Sammlung gleichartig strukturierter Datensätze. Jede Zeile beschreibt einen einzelnen Datensatz, während die Spalten Eigenschaften wie Name, Datum, Preis oder Status festlegen.

Was macht SELECT?

SELECT liest Daten und legt fest, welche Spalten das Ergebnis enthalten soll. Klauseln wie WHERE, JOIN, GROUP BY und ORDER BY können die Zeilen filtern, verknüpfen, gruppieren und sortieren.

Was ist ein JOIN?

Ein JOIN kombiniert passende Zeilen aus mehreren Tabellen für ein Abfrageergebnis. Dadurch können Kundendaten und Rechnungen getrennt gespeichert und bei Bedarf über die Kunden-ID zusammen ausgegeben werden.

Was ist ein Primärschlüssel?

Ein Primärschlüssel ist eine Spalte oder Spaltenkombination, die jede Tabellenzeile eindeutig identifiziert. Seine Werte müssen eindeutig und dürfen nicht NULL sein. Andere Tabellen können über Fremdschlüssel darauf verweisen.

Was ist SQL-Injection?

SQL-Injection bezeichnet die Manipulation einer beabsichtigten Datenbankabfrage durch unsicher eingebaute Eingaben. Parametrisierte Abfragen beziehungsweise Prepared Statements trennen SQL-Struktur und Werte und bilden deshalb die wichtigste technische Schutzmaßnahme.

Warum sollte man vor SQL-Änderungen ein Backup machen?

Ein geprüftes Backup schafft einen Wiederherstellungspunkt, falls eine Änderung Daten beschädigt oder eine Strukturmigration scheitert. Es ersetzt weder die Kontrolle der WHERE-Bedingung noch eine Transaktion: Der Filter bestimmt die Zielzeilen, die Transaktion schützt einen laufenden mehrstufigen Vorgang und das Backup unterstützt die spätere Wiederherstellung.

Für produktive Änderungen gilt deshalb eine belastbare Arbeitsregel: Wählen und prüfen Sie zuerst die Zielzeilen, führen Sie die Änderung innerhalb einer geeigneten Transaktion aus, kontrollieren Sie das Ergebnis und bestätigen Sie erst danach. Halten Sie unabhängig davon ein getestetes Wiederherstellungskonzept bereit.