Datenbanktabellen erstellen und ändern mit SQL

Eine Tabellendefinition beschreibt, was jede Zeile enthalten kann. Sie fügt keine Zeilen hinzu. In einem Onlineshop benötigt jedes Produkt eigene Felder für Kennung, Name, Preis und Lagerbestand.

Die Definition erstellen

CREATE TABLE products (
  id INTEGER PRIMARY KEY,
  name TEXT NOT NULL,
  price NUMERIC(8, 2) NOT NULL,
  in_stock INTEGER DEFAULT 0
);

Lies von außen nach innen. CREATE TABLE products benennt die neue Tabelle. Die Klammern enthalten ihre Spaltendefinitionen. Jede Zeile gibt einen Spaltennamen, einen Typ und mögliche Regeln für diese Spalte an. Kommas trennen die Definitionen; nach der letzten Definition steht kein Komma. Das Semikolon beendet die Anweisung. Nach ihrer erfolgreichen Ausführung gibt SELECT * FROM products; keine Zeilen zurück.

Diese Schlüsseldeklaration generiert IDs in SQLite. In PostgreSQL verwendest du dafür id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY. Auch die Dezimaltypdeklaration verhält sich in diesen Systemen unterschiedlich; eine exakte Speicherung zu wählen gehört zur Typwahl.

Jede Angabe erhält eine eigene Spalte

Eine Kundenzeile könnte id, first_name, last_name, email und signup_date enthalten. Wenn „Ana Ruiz, ana@example.com“ in einem Feld steht, lassen sich Name und E-Mail-Adresse nur schwer getrennt durchsuchen oder prüfen. Benenne die Felder nach ihrem Inhalt. Kurze Namen in Kleinbuchstaben, die durch Unterstriche verbunden sind, etwa unit_price, lassen sich leicht wiederverwenden.

Vermeide Schlüsselwörter als Namen: orders funktioniert, während order ohne Anführungszeichen mit dem SQL-Schlüsselwort ORDER kollidiert. Ein Name mit Leerzeichen braucht bei jeder Verwendung doppelte Anführungszeichen, wie in "order date". PostgreSQL wandelt Namen ohne Anführungszeichen in Kleinbuchstaben um, sodass Products und products ohne Anführungszeichen denselben Namen bezeichnen.

Einfache Anführungszeichen haben eine andere Aufgabe: Sie schließen Textwerte wie 'Desk lamp' ein. Doppelte Anführungszeichen kennzeichnen Namen. PostgreSQL liest "Desk lamp" als Spaltennamen, nicht als Produkttext.

Das Ergebnis prüfen

Ein abschließendes Komma vor ) verursacht einen Syntaxfehler. Ein fehlendes Komma tut das häufig ebenfalls, aber SQLite kann mehrere Wörter als einen Typnamen lesen. CREATE TABLE t (a INTEGER b TEXT); erstellt eine Spalte namens a, nicht zwei Spalten. Prüfe die Definition:

• SQLite-Shell: .schema products gibt die Erstellungsanweisung aus.
• SQLite-SQL: PRAGMA table_info(products); listet Spalten und Typen auf.
• PostgreSQL-psql: \d products zeigt Spalten, Typen und Integritätsbedingungen.

CREATE TABLE IF NOT EXISTS products (...) vermeidet einen Fehler, wenn der Name bereits vorhanden ist. Die Anweisung vergleicht oder aktualisiert die alte Definition nicht. Fehlt der Tabelle eine benötigte Spalte, bleibt das so.

Eine einmalige Kopie erstellen

CREATE TABLE cheap_products AS
SELECT name, price FROM products WHERE price < 10;

Dies erstellt Spalten und kopiert die Zeilen der Abfrage. Spätere Produktänderungen aktualisieren die Kopie nicht. In SQLite und PostgreSQL übernimmt die neue Tabelle weder den Primärschlüssel noch die NOT NULL- oder CHECK-Regeln der Quelle.

CREATE, ALTER und DROP gehören zur Datendefinitionssprache, kurz DDL: Sie ändern die Struktur. INSERT, UPDATE und DELETE gehören zur Datenmanipulationssprache, kurz DML: Sie ändern Zeilen. SELECT liest Daten; Bücher unterscheiden sich darin, ob sie es zu DML zählen oder Abfragen eine eigene Gruppe geben.

Wähle den Typ nach der Aufgabe des Werts. Mit einer Menge muss man rechnen können. Eine Postleitzahl muss ihre Zeichen einschließlich führender Nullen behalten. Beide können Ziffern enthalten, brauchen aber unterschiedliche Speicherformen.

Zahlen- und Texttypen wählen

In PostgreSQL hat NUMERIC(8, 2) insgesamt acht Ziffern, zwei davon nach dem Komma. Der größte positive Wert ist 999.999,99. Beim Einfügen von 12,345 wird 12,35 gespeichert; 1.234.567,00 führt zu einem Überlauf, weil der Wert sieben Ziffern vor dem Komma benötigt. DECIMAL ist ein anderer Name für diese Typfamilie.

SQLite akzeptiert NUMERIC(8, 2), setzt aber weder die Genauigkeit noch die Dezimalstellenanzahl durch. Es speichert 19,99 als Gleitkommazahl und behält 12,345 ungerundet bei. Speichere für einen exakten Betrag von 19,99 insgesamt 1.999 ganze Cent. Gleitkommazahlen nähern binäre Brüche an: SELECT 0.1 + 0.2 = 0.3; liefert in SQLite 0. PostgreSQL behandelt diese Dezimalliterale ohne weitere Typangabe als exakte numerische Werte; wandle sie in DOUBLE PRECISION um, um das Näherungsergebnis zu sehen.

Zahlen als Text werden nach Zeichen sortiert: '100', '25', '9' erscheinen in dieser Reihenfolge. Numerische Mengen brauchen Zahlenspalten. Die US-Postleitzahl '02139' gehört in eine Textspalte; bei ganzzahliger Speicherung geht ihre führende Null verloren.

PostgreSQL lehnt bei VARCHAR(20) Text mit mehr als 20 Zeichen ab. Sein CHAR(n) füllt kürzeren Text mit Leerzeichen auf eine feste Länge auf. Für TEXT ist keine Zeichenbegrenzung deklariert. SQLite behandelt sowohl VARCHAR(n) als auch CHAR(n) als Text, ohne die Länge durchzusetzen oder aufzufüllen.

Datums- und Ja-Nein-Werte speichern

PostgreSQL hat DATE, TIME, TIMESTAMP und BOOLEAN. Es lehnt ein unmögliches DATE wie '2026-02-30' ab. SQLite hat keinen eigenen Speichertyp für Datumswerte. Verwende ISO-Text wie '2026-03-15', dessen Zeichenreihenfolge der Datumsreihenfolge entspricht. Text im US-Format sortiert Datumswerte über Jahresgrenzen hinweg falsch: '12/01/2025' steht nach '03/15/2026'.

Ein Zeitstempel ergänzt eine Uhrzeit, etwa '2026-03-15 14:30:00'. PostgreSQL verwendet TRUE und FALSE für boolesche Werte; SQLite speichert 1 und 0 und akzeptiert diese Schlüsselwörter. MySQL behandelt BOOLEAN als kleine Ganzzahl; SQL Server verwendet BIT.

Wissen, was das System durchsetzt

Gewöhnliche SQLite-Tabellen verwenden Typaffinität, eine Präferenz für die Speicherung. Eine INTEGER-Spalte wandelt '5' in 5 um, akzeptiert aber 'abc' als Text. PostgreSQL lehnt Text ab, der nicht in eine Ganzzahl umgewandelt werden kann. SQLite ab 3.37.0 unterstützt STRICT-Tabellen mit den erlaubten Typen INT, INTEGER, REAL, TEXT, BLOB und ANY.

Wähle für Bestellungen eine ganzzahlige id, Text für die E-Mail-Adresse, ein PostgreSQL-DATE oder einen SQLite-Datumswert als ISO-Text, PostgreSQL-NUMERIC(10, 2) oder ganzzahlige Centbeträge in SQLite für den Gesamtbetrag und ein boolesches oder ein 0/1-Flag für die Zahlung. NULL bedeutet fehlend oder unbekannt; es ist weder ein Typ noch dasselbe wie null oder eine leere Zeichenkette. Eine Spalte akzeptiert es, sofern eine Regel es nicht verbietet.

Eine Integritätsbedingung sorgt dafür, dass die Datenbank Daten ablehnt, die gegen eine deklarierte Regel verstoßen. Die Prüfung erfolgt beim Einfügen oder Aktualisieren von Zeilen, unabhängig davon, welche Anwendung die Anweisung sendet. Verschiedene Regeln schützen verschiedene Teile eines Produktdatensatzes.

Regeln in einer Tabelle kombinieren

Diese SQLite-Definition generiert den Schlüssel und prüft die anderen Felder. Für PostgreSQL ersetzt du die Schlüsselzeile durch einen Primärschlüssel als Identitätsspalte.

CREATE TABLE products (
  id INTEGER PRIMARY KEY,
  sku TEXT NOT NULL UNIQUE,
  name TEXT NOT NULL,
  price NUMERIC(8, 2) NOT NULL CHECK (price > 0),
  in_stock INTEGER NOT NULL DEFAULT 0 CHECK (in_stock >= 0)
);

NOT NULL schreibt einen Wert vor. UNIQUE verhindert eine wiederholte Artikelnummer. CHECK (price > 0) lehnt Preise ab, die null oder negativ sind. Der Lagerbestand hat den Standardwert 0 und darf nicht negativ sein. Die numerische Deklaration in SQLite ermöglicht keine exakte Dezimalrechnung. Verwende daher ganze Centbeträge, wenn es auf Exaktheit ankommt.

Auslassen und NULL unterscheiden

Füge eine Schreibtischlampe mit der Artikelnummer 'LAMP-01', dem Namen 'Desk lamp' und dem Preis 24,99 ein und lass den Lagerbestand in der Spaltenliste aus. Die Einfügung gelingt und erhält den Lagerbestand 0. Ein angegebenes NULL für den Lagerbestand fordert den Standardwert nicht an: Es verstößt gegen NOT NULL.

Ein Kaffeebecher zum Preis von −3,50 verstößt gegen die Preisprüfung. Ein zweites Produkt mit der Artikelnummer 'LAMP-01' verstößt gegen UNIQUE, auch wenn sich Name und Preis unterscheiden. Ein Stift ohne Namen verstößt gegen NOT NULL. Lies im Fehler, welche Regel oder Spalte genannt wird, und korrigiere die Eingabe.

Eine leere Zeichenkette ist ein echter Wert. name TEXT NOT NULL akzeptiert '' in SQLite und PostgreSQL. Ergänze CHECK (name <> ''), um sie abzulehnen. Oracle behandelt leeren Text als NULL, sodass dort für dieselbe Eingabe eine andere Regel gilt.

Kombinationen und fehlende Werte prüfen

Eine Spaltenregel folgt auf den Typ der Spalte. Eine Tabellenregel ist ein eigener Eintrag innerhalb der Tabellendefinition und kann Spalten vergleichen:

CHECK (end_date >= start_date),
UNIQUE (order_id, product_id)

Die erste Regel lehnt ein Enddatum vor einem Startdatum ab. Die zweite lehnt ein wiederholtes Paar ab: Ein Produkt kann in verschiedenen Bestellungen vorkommen, aber nicht zweimal in derselben Bestellung. Eine Tabelle kann mehrere Eindeutigkeitsbedingungen haben.

Eine Prüfung lehnt eine Zeile ab, wenn ihre Bedingung falsch ist. Ist der Preis NULL, ist price > 0 unbekannt, sodass die Prüfung bestanden wird. Deshalb braucht der Produktpreis auch NOT NULL. PostgreSQL, SQLite und MySQL erlauben unter UNIQUE normalerweise mehrere NULL-Werte; SQL Server erlaubt bei einer Eindeutigkeitsbedingung für eine einzelne Spalte einen. PostgreSQL ab Version 15 bietet UNIQUE NULLS NOT DISTINCT, wenn auch fehlende Werte miteinander kollidieren sollen. MySQL-Versionen vor 8.0.16 ignorierten CHECK-Regeln.

Gib einer Regel mit CONSTRAINT price_positive CHECK (price > 0) einen sinnvollen Namen. Der Name hilft, sie in einem Fehler zu erkennen und später zu entfernen. Eine Integritätsbedingung prüft genau ihren Ausdruck: CHECK (email LIKE '%@%') erkennt ein fehlendes At-Zeichen, aber keinen Tippfehler in einer ansonsten passenden Adresse.

Ein Primärschlüssel identifiziert eine Zeile zuverlässig. Er kann aus einer Spalte oder einer Kombination bestehen, eine Tabelle hat aber höchstens einen Primärschlüssel. Der Schlüssel muss eindeutig und vorhanden sein, damit andere Anweisungen eine Zeile unabhängig von ihrer Beschreibung benennen können.

Eine stabile Kennung wählen

Ein natürlicher Schlüssel ist eine vorhandene Kennung aus der realen Welt, etwa die ISBN eines Buches. Ein Surrogatschlüssel ist eine künstliche Kennung, oft eine generierte Ganzzahl. Die E-Mail-Adresse eines Kunden kann sich ändern; eine generierte Kunden-ID kann dabei gleich bleiben.

Ein zusammengesetzter Schlüssel identifiziert eine Kombination:

PRIMARY KEY (order_id, product_id)

Eine Bestellung kann mehrere Produkte enthalten, und ein Produkt kann in mehreren Bestellungen vorkommen. Das Paar identifiziert eine Bestellposition. Keine der beiden Spalten muss für sich genommen eindeutig sein.

PostgreSQL, MySQL und SQL Server setzen voraus, dass Primärschlüssel nicht fehlen. Gewöhnliche SQLite-Tabellen behalten eine historische Ausnahme bei: Ein anderer Primärschlüssel als INTEGER PRIMARY KEY kann NULL enthalten. Verwende code TEXT PRIMARY KEY NOT NULL für einen Textschlüssel. SQLite-STRICT-Tabellen schließen diese Lücke ebenfalls.

Die Datenbank die Nummer generieren lassen

Lass id in der Spaltenliste der Einfügung aus, um einen generierten Wert anzufordern. Ein einfaches PostgreSQL-INTEGER PRIMARY KEY generiert keinen Wert. Älterer PostgreSQL-Code verwendet häufig SERIAL.

In SQLite ist INTEGER PRIMARY KEY ein Alias für die interne Zeilennummer. Beginne mit den generierten IDs 1, 2 und 3 und lösche dann 3. Die nächste regulär generierte ID ist wieder 3, also eins über dem aktuellen Maximum. Mit INTEGER PRIMARY KEY AUTOINCREMENT ist sie 4: Eine Nummer, die eine festgeschriebene Zeile hatte, wird nicht erneut verwendet. Eine Nummer aus einer zurückgesetzten Einfügung kann dennoch erneut verwendet werden. Diese stärkere Garantie verursacht zusätzlichen Aufwand, wähle sie daher, wenn es darauf ankommt, eine Wiederverwendung auszuschließen.

IDs lesen, ohne sie als Anzahlen zu behandeln

Lücken sind normal. Löschungen hinterlassen sie, und PostgreSQL gibt Sequenznummern nach fehlgeschlagenen oder zurückgesetzten Einfügungen nicht zurück. Verwende COUNT(*) für eine Zeilenanzahl und einen Zeitstempel für den Zeitpunkt eines Ereignisses. Die größte ID beantwortet keine der beiden Fragen zuverlässig.

Die PostgreSQL-Form GENERATED ALWAYS lehnt eine ausdrücklich angegebene ID wie 50 normalerweise ab. GENERATED BY DEFAULT und SERIAL akzeptieren ausdrückliche Werte, aber die Angabe von 50 setzt den Generator nicht hinter 50. Ein später generierter Wert kann damit kollidieren.

Um den Schlüssel einer neuen Zeile in einer zugehörigen Zeile zu verwenden, lies ihn aus:

INSERT INTO customers (first_name, last_name, email)
VALUES ('Dev', 'Patel', 'dev@example.com')
RETURNING id;

RETURNING funktioniert in PostgreSQL und ab SQLite 3.35.0. SQLite bietet außerdem last_insert_rowid(), MySQL bietet LAST_INSERT_ID(), und SQL Server verwendet OUTPUT. Lies das Ergebnis der Einfügung, statt die nächste ID zu erraten.

Die customer_id einer Bestellung sollte auf einen vorhandenen Kunden verweisen. Ein Fremdschlüssel veranlasst die Datenbank, diese Verknüpfung zu prüfen. Die Tabelle mit dem Verweis ist die Kindtabelle; die Tabelle, auf die sie verweist, ist die Elterntabelle.

Die Verknüpfung deklarieren und durchsetzen

CREATE TABLE orders (
  id INTEGER PRIMARY KEY,
  customer_id INTEGER NOT NULL REFERENCES customers(id)
);

Hier muss customers zuerst existieren, und seine id muss ein Primärschlüssel oder eindeutiger Schlüssel sein. Stimme die Typen auf beiden Seiten aufeinander ab. Die Tabellenform FOREIGN KEY (customer_id) REFERENCES customers(id) deklariert dieselbe Verknüpfung getrennt von der Spalte.

Bei eingeschalteter Fremdschlüsselprüfung schlägt eine Bestellung für Kunde 99 fehl, wenn kein Kunde 99 existiert. Auch das Aktualisieren einer Bestellung auf diesen fehlenden Kunden schlägt fehl. Ein Fremdschlüssel, der NULL zulässt, kann NULL enthalten, was bedeutet, dass keine Zeile verknüpft ist; NOT NULL schreibt die Verknüpfung vor.

Führe in SQLite bei jeder neuen Verbindung PRAGMA foreign_keys = ON; aus, bevor du eine Transaktion startest. Eine Änderung der Einstellung innerhalb einer Transaktion hat keine Wirkung. PostgreSQL und SQL Server setzen Fremdschlüssel normalerweise durch, ebenso die Standard-Engine InnoDB von MySQL.

Das Löschen einer Elternzeile vorhersagen

Nimm die Kunden 1, Ana, und 2, Ben. Die Bestellungen 101 und 102 gehören Ana; 103 gehört Ben. Betrachte, was beim Löschen von Kunde 1 unter verschiedenen Deklarationen geschieht:

SET NULL benötigt eine Spalte, die NULL zulässt. SET DEFAULT muss weiterhin den Fremdschlüssel erfüllen: Ein nicht fehlender Standardwert muss eine vorhandene Elternzeile identifizieren. Ein NULL-Standardwert funktioniert, wenn fehlende Verknüpfungen erlaubt sind.

Wähle nach der Bedeutung der Daten. Bestellpositionen gehören oft vollständig zu ihrer Bestellung, sodass eine Kaskadierung passen kann. Bei Bestellungen, die erhalten bleiben müssen, ist eine blockierende Aktion passend, wenn jemand ihren Kunden entfernen möchte. Eine optionale Lieferantenverknüpfung kann auf NULL gesetzt werden. Werden Kaskadierungen überall eingesetzt, kann eine Löschung mehr Datensätze entfernen, als der Name ihrer Tabelle vermuten lässt.

In der Reihenfolge der Abhängigkeiten arbeiten

Erstelle Elterntabellen vor Kindtabellen und füge Elternzeilen vor den Zeilen ein, die auf sie verweisen. Arbeite beim Entfernen zusammengehöriger Daten oder Tabellen von den Kindtabellen zu den Elterntabellen. Eine ON UPDATE-Aktion bietet dieselben Möglichkeiten, wenn sich der Schlüssel der Elternzeile ändert; ON UPDATE CASCADE kopiert den neuen Schlüssel in die Kindzeilen.

RESTRICT prüft sofort. NO ACTION, die Standardeinstellung, kann bis zum Ende der Anweisung oder bei einer aufschiebbaren Integritätsbedingung bis zum Ende der Transaktion warten. Beide blockieren eine gewöhnliche Löschung, die Verweise ohne passende Elternzeile hinterlassen würde. Halte generierte IDs stabil, damit eine Änderung der Kundendaten nicht erfordert, jeden Verweis auf diesen Kunden zu ändern.

INSERT fügt einer bestehenden Tabelle Zeilen hinzu. Die Spaltenliste ordnet die angegebenen Werte den Feldern zu, die sie aufnehmen. Schreibe diese Zuordnung ausdrücklich, damit eine spätere Tabellenänderung die Bedeutung deiner Eingabe nicht unbemerkt ändert.

Werte anhand ihrer Position zuordnen

INSERT INTO products (sku, name, price, in_stock)
VALUES ('LAMP-01', 'Desk lamp', 24.99, 12);

Lies die Paare der Reihe nach: Die Artikelnummer erhält 'LAMP-01', der Name erhält 'Desk lamp', der Preis erhält 24,99 und der Lagerbestand 12. Für diese vier Spalten muss es vier Werte geben. Eine Abweichung wie zwei Werte für drei Spalten führt zu einem Fehler.

Ohne die Liste folgen die Werte der deklarierten Spaltenreihenfolge der Tabelle. SQLite verlangt eine Angabe für alle Spalten; PostgreSQL erlaubt weniger und gibt den hinteren Spalten ihre Standardwerte. Mit einer ausdrücklichen Liste musst du dich auf keines dieser beiden Verhaltensweisen verlassen. Außerdem kannst du die Spalten in eine für die Eingabe klare Reihenfolge bringen.

Ein vertauschtes Paar kann schlimmer sein als ein Syntaxfehler. Gibst du 9,99 als Namen und 'Desk lamp' als Preis an, lehnt PostgreSQL den nicht numerischen Preis ab. Die gewöhnliche Typaffinität von SQLite kann den Namenstext „9.99“ und den Preistext „Desk lamp“ ohne Fehler speichern. Lies die eingefügte Zeile mit SELECT aus, um die Zuordnung zu prüfen.

Literale richtig schreiben

Der doppelte Apostroph speichert einen Apostroph. Zahlen haben kein Währungszeichen und kein Tausendertrennzeichen; ein Komma trennt Werte, daher ändert ein Komma innerhalb eines Betrags ohne Anführungszeichen die Anzahl der Werte. 'NULL' ist der vierbuchstabige Text „NULL“, kein fehlender Wert.

Ausgelassene Felder automatisch füllen lassen

Eine ausgelassene Spalte erhält ihren Standardwert oder NULL, wenn sie keinen hat. Ein generierter Schlüssel erhält einen generierten Wert. Dieses letzte Verhalten hängt von der Deklaration ab: INTEGER PRIMARY KEY von SQLite generiert IDs; PostgreSQL benötigt dafür eine Identitätsdeklaration. Wird ein einfacher ganzzahliger Primärschlüssel in PostgreSQL bei einer Einfügung ausgelassen, schlägt sie fehl, weil sein Wert NULL wäre.

PostgreSQL, MySQL und SQL Server erlauben DEFAULT als Platzhalter für einen Wert. SQLite akzeptiert es nicht innerhalb einer VALUES-Liste; lass diese Spalte stattdessen aus. Ein ausdrückliches NULL fordert nie den Standardwert an.

Mehrere Zeilen zusammen hinzufügen

INSERT INTO customers (first_name, last_name, email) VALUES
  ('Ana', 'Ruiz', 'ana@example.com'),
  ('Ben', 'Okafor', 'ben@example.com'),
  ('Chloe', 'Nguyen', 'chloe@example.com');

In einer leeren Tabelle, deren generierter Schlüssel bei 1 beginnt, erhalten diese Kunden die IDs 1, 2 und 3. Bei gewöhnlicher Behandlung von Integritätsbedingungen gelingt oder scheitert die mehrzeilige Anweisung als Ganzes. Verstößt eine Zeile gegen eine Regel, wird keine Zeile dieser Anweisung eingefügt.

Ein UNIQUE-Fehler weist auf einen doppelten Schlüssel oder Wert hin; NOT NULL weist auf fehlende Daten hin; CHECK weist auf eine nicht erfüllte Bedingung hin; und ein Fremdschlüsselfehler weist auf eine ungültige Verknüpfung hin. Korrigiere den Wert oder seine beabsichtigte Zuordnung, bevor du es erneut versuchst.

Zeilen müssen nicht einzeln eingegeben werden. Eine Abfrage kann die Zeilen für eine Einfügung liefern, und eine Konfliktregel kann festlegen, was geschieht, wenn ein eindeutiger Wert bereits existiert. Bei beiden Funktionen kommt es darauf an, genau die gewünschten Daten zu treffen.

Ein Abfrageergebnis kopieren

INSERT INTO archived_orders (id, customer_id, order_date, total)
SELECT id, customer_id, order_date, total
FROM orders
WHERE order_date < '2026-01-01';

Es gibt keine VALUES-Klausel: Die Abfrage liefert die Werte. Ordne ihre ausgewählten Spalten anhand ihrer Position der Zielliste zu. Die Zieltabelle muss bereits existieren, und ihre Regeln gelten weiterhin.

Sieh dir das SELECT zuerst allein an. Die Bestellungen 201, 202 und 204 haben die Datumswerte 2025-11-03, 2025-12-19 und 2025-10-30 sowie die Gesamtbeträge 45,00, 120,50 und 60,00. Die Bestellungen 203 und 205 stammen aus dem Jahr 2026. Die Abfrage gibt drei Zeilen mit einer Summe von 225,50 zurück, und die Einfügung kopiert diese drei. Sie kann auch null Zeilen kopieren, wenn der Filter nichts findet.

Ein zweiter Durchlauf versucht, sie erneut zu kopieren. Ein Primärschlüssel in der Zieltabelle lässt dies fehlschlagen, statt unbemerkt Duplikate zu speichern. INSERT ... SELECT ist ein Kopiervorgang; er entfernt weder die Quellzeilen noch hält er die beiden Tabellen synchron.

Dateiimporte laufen oft zuerst über eine Staging-Tabelle. Die Shell von SQLite verwendet .import --csv file.csv staging, psql verwendet \copy. In einer späteren Abfrage entfernt TRIM(email) umgebende Leerzeichen und NULLIF(TRIM(email), '') wandelt eine leere oder nur aus Leerzeichen bestehende E-Mail-Adresse in NULL um. Die Integritätsbedingungen der Zieltabelle prüfen anschließend die bereinigten Zeilen.

Das Ergebnis eines Schreibvorgangs auslesen

INSERT INTO customers (first_name, last_name, email)
VALUES ('Dev', 'Patel', 'dev@example.com')
RETURNING id;

Das Ergebnis liefert die generierte Kunden-ID zur Verwendung in einer zugehörigen Zeile. PostgreSQL und SQLite ab 3.35.0 unterstützen RETURNING bei Einfügungen, Aktualisierungen und Löschungen. MySQL verwendet LAST_INSERT_ID() für eine generierte ID; SQL Server verwendet OUTPUT.

Über den Umgang mit Duplikaten entscheiden

Nimm bei stock (sku TEXT PRIMARY KEY, qty INTEGER NOT NULL) an, dass 'LAMP-01' die Menge 12 hat. Eine einfache Einfügung mit derselben Artikelnummer und der Menge 20 schlägt fehl. In SQLite und PostgreSQL:

INSERT INTO stock (sku, qty) VALUES ('LAMP-01', 20)
ON CONFLICT (sku) DO UPDATE
SET qty = stock.qty + excluded.qty;

stock.qty ist der vorhandene Wert 12. excluded.qty ist der vorgesehene Wert 20. Diese Form speichert 32, was zu einer zusätzlichen Lieferung passt. SET qty = excluded.qty speichert 20, was zu einem ersetzenden Bestandswert passt. DO NOTHING behält 12 bei und überspringt die Zeile, die den Konflikt auslöst. Jede Variante geht von derselben ursprünglichen Menge 12 aus.

Ein Upsert verbindet das Einfügen einer neuen Zeile mit einer Aktualisierung bei einem Konflikt. Das Konfliktziel muss durch eine geeignete Eindeutigkeitsregel geschützt sein. Die entsprechende Anweisungsfamilie in MySQL ist ON DUPLICATE KEY UPDATE. Ein einfaches INSERT korrigiert keinen vorhandenen Kunden: Es erstellt entweder eine weitere Zeile oder stößt auf einen Eindeutigkeitsfehler. Verwende UPDATE für eine bekanntermaßen vorhandene Zeile und einen Upsert, wenn die Zeile bereits existieren könnte.

UPDATE ändert Werte in bereits vorhandenen Zeilen. Die Anweisung nennt eine Tabelle, weist mit SET neue Werte zu und wählt dann mit WHERE die Zielzeilen aus. Die Integritätsbedingungen der Tabelle prüfen die entstehenden Werte.

Ein oder mehrere Felder setzen

UPDATE products
SET price = 22.50, in_stock = 30
WHERE id = 3;

Das Produkt mit dem Schlüssel 3 erhält beide Werte; andere Zeilen behalten ihre Werte. Zuweisungen werden durch Kommas getrennt. SET price = 22.50 AND in_stock = 30 bedeutet nicht zwei Zuweisungen. PostgreSQL lehnt dies ab; SQLite behandelt die rechte Seite als booleschen Ausdruck und kann 0 oder 1 im Preis speichern.

Ein fehlendes WHERE ist gültiges SQL und betrifft jede Zeile. UPDATE products SET price = 0; setzt den Preis jedes Produkts auf null, sofern die Regeln der Tabelle dies erlauben. Eine Vorschau mit der vorgesehenen Bedingung zeigt, ob eine Zeile, mehrere Zeilen oder keine getroffen werden.

Mit dem gespeicherten Wert rechnen

UPDATE products
SET price = price * 1.10;

Ein Preis von 20,00 wird nach einer Erhöhung um 10 % zu 22,00. Ein Preis von 19,99 ergibt ungerundet 21,989. PostgreSQL speichert in einer NUMERIC(8, 2)-Spalte 21,99. SQLite setzt die Dezimalstellenanzahl nicht durch, daher fordert SET price = ROUND(price * 1.10, 2) zwei Dezimalstellen an. Für eine exakte Speicherung von Geldbeträgen in SQLite speichere ganze Cent und lege ausdrücklich fest, wie Centbeträge gerundet werden.

Der Ausdruck muss den alten Wert enthalten, wenn die Änderung relativ ist. SET in_stock = in_stock - 1 entfernt eine Einheit; SET in_stock = 1 ersetzt den Bestand durch eins.

In SQLite und PostgreSQL lesen alle Ausdrücke auf der rechten Seite die Zeile vor der Aktualisierung. UPDATE t SET a = b, b = a; vertauscht die Werte einer Zeile von 1 und 2 zu 2 und 1. Bei einem Update einer einzelnen Tabelle wertet MySQL die Zuweisungen von links nach rechts aus, sodass dieselbe Form beide Werte auf 2 setzt. Übertrage diese Annahme nicht zwischen Systemen.

Regeln und fehlende Werte beachten

Verwende SET phone = NULL, um ein Telefonfeld zu leeren. Um fehlende Telefonwerte zu finden, verwende WHERE phone IS NULL. Ein Gleichheitsvergleich mit NULL findet sie nicht.

Betrachte die Preise 12,00, 3,00 und 8,50, die durch CHECK (price > 0) geschützt sind. Würdest du von jedem Preis 5 abziehen, würde der zweite zu −2,00. Bei gewöhnlicher Behandlung von Integritätsbedingungen macht dieser Fehler die ganze Anweisung rückgängig, sodass auch die ansonsten zulässigen Preise unverändert bleiben.

Auch eine Änderung des Primärschlüssels muss zugehörige Fremdschlüssel erfüllen. Eine blockierte Schlüsseländerung schlägt fehl, solange Kindzeilen auf den alten Schlüssel verweisen; ON UPDATE CASCADE überträgt den neuen Wert in diese Zeilen. Bleiben generierte IDs stabil, entfällt dieser zusätzliche Aufwand bei Änderungen beschreibender Angaben.

Die Anzahl betroffener Zeilen deuten

psql meldet ein Ergebnis wie UPDATE 3; changes() von SQLite meldet die Anzahl für die letzte Änderungsanweisung. Beide zählen auch getroffene und aktualisierte Zeilen, bei denen der zugewiesene Wert dem alten entspricht. Eine Anzahl von drei verspricht nicht drei sichtbar unterschiedliche Werte. Vergleiche die Anzahl mit der Vorschau und prüfe anschließend die betreffenden Felder oder verwende RETURNING, um betroffene Zeilen direkt zu sehen.

DELETE entfernt ganze Zeilen. Die Tabelle bleibt bestehen und kann wieder Zeilen aufnehmen. Um ein einzelnes Feld zu leeren, verwendest du UPDATE ... SET column = NULL; DELETE email FROM customers ist kein gültiges SQL.

Eine gefilterte Löschung nachvollziehen

Der Shop hat diese Bestellungen:

DELETE FROM orders
WHERE status = 'cancelled'
  AND order_date < '2026-01-01';

Bestellung 201 erfüllt beide Bedingungen, ebenso 204. Bestellung 203 ist storniert, aber zu neu; 202 ist alt genug, aber versandt. Die Anweisung entfernt zwei Zeilen und lässt 202, 203 und 205 bestehen. DELETE FROM orders; ohne die Bedingung würde alle fünf entfernen.

Zeilen anhand zugehöriger Daten auswählen

DELETE FROM order_items
WHERE order_id IN (
  SELECT id FROM orders WHERE status = 'cancelled'
);

Die innere Abfrage liefert die IDs stornierter Bestellungen. IN prüft die order_id jeder Position gegen diese Liste. Führe die innere Abfrage allein aus, um die Schlüssel zu prüfen, und sieh dir dann die Positionszeilen mit derselben Bedingung vorab an.

Auch Fremdschlüssel beeinflussen Löschungen. Eine Elternzeile, auf die Kindzeilen verweisen, kann durch NO ACTION oder RESTRICT geschützt werden; eine Kaskadierung entfernt Kindzeilen; SET NULL erhält Kindzeilen, entfernt aber die Verknüpfung. Prüfe diese Aktionen, wenn du die Wirkung des Löschens einer Elternzeile beurteilst, denn die direkt genannte Tabelle muss nicht die einzige geänderte Tabelle sein.

Wählen, was erhalten bleiben soll

PostgreSQL, MySQL, SQL Server und Oracle unterstützen TRUNCATE; SQLite nicht. Die Transaktions- und Abhängigkeitsregeln dafür unterscheiden sich je nach Datenbank. Auch eine Anweisung, die wie ein schnelles Leeren klingt, muss diese Regeln einhalten.

Die Historie durch logisches Löschen erhalten

UPDATE customers
SET deleted_at = '2026-03-15'
WHERE id = 7;

Beim logischen Löschen wird die Zeile markiert, ohne sie zu entfernen. Dadurch kann die Historie erhalten bleiben und die Zeile durch Entfernen der Markierung wiederhergestellt werden. Abfragen nach aktiven Kunden müssen WHERE deleted_at IS NULL enthalten; andernfalls erscheinen die markierten Kunden weiterhin. Das Markieren von Daten löscht sie nicht.

Eine festgeschriebene Löschung lässt sich durch ein späteres ROLLBACK nicht rückgängig machen. Für die Wiederherstellung braucht man eine gespeicherte Kopie oder Sicherung. Innerhalb einer offenen Transaktion kann ein Rollback gelöschte Zeilen noch wiederherstellen. Prüfe die ausgewählten IDs und die Anzahl betroffener Zeilen, bevor du das Ergebnis dauerhaft festschreibst.

Die Auswahl der Zeilen ist oft der schwierigste Teil einer Änderung. Derselbe Filter, der in einer Abfrage harmlos ist, kann bei seiner Wiederverwendung in einem Schreibvorgang zu viel löschen oder aktualisieren. Formuliere die beabsichtigte Regel als Bedingung und prüfe dann, worauf sie tatsächlich zutrifft.

Genau die Bedingung vorab prüfen

SELECT id, status, order_date FROM orders
WHERE status = 'cancelled'
  AND order_date < '2026-01-01';

Diese Vorschau gibt im Shop-Beispiel mit fünf Bestellungen die Bestellungen 201 und 204 zurück. Verwende genau diese Bedingung für die Löschung. Wenn du sie beim Ändern des Befehls umformulierst, entsteht eine neue, ungeprüfte Auswahl.

Für eine bestimmte Zeile verwende ihren Primärschlüssel: WHERE id = 42 trifft höchstens eine Zeile. Mehrere Produkte können denselben beschreibenden Namen wie 'Desk lamp' haben.

Alternativen ausdrücklich gruppieren

AND bindet stärker als OR. Vergleiche:

WHERE status = 'cancelled'
   OR status = 'expired' AND order_date < '2026-01-01'

mit:

WHERE (status = 'cancelled' OR status = 'expired')
  AND order_date < '2026-01-01'

Die erste Bedingung akzeptiert jede stornierte Bestellung unabhängig vom Datum sowie vor 2026 abgelaufene Bestellungen. Sie trifft auf 201, 203 und 204 zu. Die zweite wendet die Datumsprüfung auf beide Statuswerte an und trifft auf 201 und 204 zu. Bestellung 203 zeigt den Unterschied, weil sie 2026 storniert ist.

Fehlende Werte bewusst einbeziehen

WHERE customer_id = NULL trifft keine Zeilen. Fehlende Werte brauchen IS NULL oder IS NOT NULL. Auch eine negative Prüfung hat eine Lücke: status <> 'shipped' schließt einen fehlenden Status nicht ein, weil das Vergleichsergebnis unbekannt ist.

Gehört ein fehlender Status zur vorgesehenen Gruppe, schreibe:

WHERE status <> 'shipped' OR status IS NULL

Wenn du eine weitere Bedingung hinzufügst, fasse diese ganze Alternative in Klammern, damit beide Zweige die weitere Bedingung erfüllen müssen.

Ein Mustervergleich kann mehr erfassen als die beabsichtigte Beschreibung. LIKE '%lamp%' trifft auf „Desk lamp“ und „Clamp“ zu. Das standardmäßige LIKE von SQLite ignoriert außerdem die Groß- und Kleinschreibung englischer Buchstaben und findet daher „Lamp shade“. Ein Muster ist nützlich, um mögliche Treffer zu finden. Prüfe diese Treffer aber, bevor du sie änderst.

Für eine Liste einen Listenvergleich wählen

UPDATE orders SET status = 'on hold'
WHERE customer_id IN (
  SELECT id FROM customers WHERE state = 'CA'
);

Die Unterabfrage kann mehrere Kunden-IDs liefern; IN prüft, ob ein Wert in der Liste enthalten ist. Ersetzt du IN durch =, wird ein einzelnes skalares Ergebnis verlangt. PostgreSQL lehnt dort mehrere Zeilen ab, während SQLite ohne Meldung die erste zurückgegebene Zeile verwendet und andere Kunden übersieht.

Vergleiche nach der Änderung die Anzahl betroffener Zeilen mit der Vorschau. PostgreSQL und SQLite können außerdem RETURNING * anhängen, um die betroffenen Zeilen anzuzeigen. Starte bei einem riskanten Schreibvorgang vor der Datenänderung eine Transaktion, prüfe das Ergebnis und wähle dann COMMIT oder ROLLBACK.

Eine Transaktion fasst zusammengehörige Anweisungen zu einer Arbeitseinheit zusammen. Du entscheidest, ob du ihre Änderungen gemeinsam mit COMMIT übernimmst oder mit ROLLBACK rückgängig machst. Die Alles-oder-nichts-Eigenschaft heißt Atomarität, das A in ACID.

Beide Seiten einer Überweisung erhalten

Mayas Konto mit der ID 1 enthält 500,00. Leos Konto mit der ID 2 enthält 120,00. Um 75,00 zu überweisen, sind zwei Änderungen nötig:

BEGIN;
UPDATE accounts SET balance = balance - 75.00 WHERE id = 1;
UPDATE accounts SET balance = balance + 75.00 WHERE id = 2;
SELECT id, balance FROM accounts WHERE id IN (1, 2);
COMMIT;

Nach der ersten Aktualisierung hat Maya 425,00. Nach der zweiten hat Leo 195,00. Die Prüfung zeigt beide Kontostände vor dem Festschreiben, und die Summe bleibt 620,00. Verwende für diese exakten Dezimalkontostände PostgreSQL-NUMERIC; eine Variante für exakte Geldbeträge in SQLite speichert 50.000 und 12.000 Cent und überweist 7.500 Cent.

Ohne ausdrückliche Transaktion könnte bei Autocommit die erste Aktualisierung dauerhaft werden, bevor die zweite ausgeführt wird. Ein Absturz dazwischen würde die Abbuchung ohne die Gutschrift übernehmen. Eine Transaktion ermöglicht eine gemeinsame endgültige Entscheidung über das Übernehmen oder Rückgängigmachen beider Aktualisierungen. Schlägt eine Anweisung fehl, behandle den Fehler, bevor du die Überweisung als abgeschlossen betrachtest.

Die standardmäßige Transaktionsgrenze verstehen

Bei Autocommit der Datenbank wird jede erfolgreiche eigenständige Anweisung als eigene Transaktion festgeschrieben. Das ist das übliche Ausgangsverhalten von SQLite, PostgreSQL, MySQL und SQL Server. Eine Programmbibliothek oder ein Client kann andere Einstellungen wählen und eine Transaktion für dich starten.

BEGIN; startet in SQLite und PostgreSQL eine ausdrückliche Transaktion. SQLite und SQL Server verwenden auch BEGIN TRANSACTION; PostgreSQL und MySQL akzeptieren START TRANSACTION. Oracle startet eine Transaktion mit einer Datenänderung und wartet in Werkzeugen wie SQL*Plus gewöhnlich auf COMMIT, sofern Autocommit nicht eingeschaltet ist.

COMMIT beendet die Transaktion und übernimmt ihre Änderungen. ROLLBACK beendet sie und macht ihre nicht festgeschriebenen Änderungen rückgängig. Ein späteres Rollback kann ein früheres Commit nicht rückgängig machen.

Prüfen und rückgängig machen

BEGIN;
DELETE FROM orders;
SELECT * FROM orders;
ROLLBACK;

Deine Verbindung sieht beim SELECT eine leere Tabelle und nach dem Rollback wieder die fünf Bestellungen. Das leere Ergebnis war innerhalb der Transaktion tatsächlich vorhanden, aber noch nicht dauerhaft. Andere Verbindungen sehen die nicht festgeschriebenen Änderungen normalerweise nicht.

Eine Transaktion kann dich vor einer falschen Zeilenauswahl nur schützen, wenn du das Ergebnis prüfst und dich für das Rückgängigmachen entscheidest. SQL kann eine nicht beabsichtigte Zeile erfolgreich aktualisieren: Keine Datenbankregel weiß, welches Konto du nennen wolltest. Vergleiche zurückgegebene IDs, Werte und Anzahlen vor dem Festschreiben mit dem beabsichtigten Ergebnis.

Halte Transaktionen kurz und beende sie. Offene Transaktionen können Sperren halten, die andere Verbindungen zum Warten bringen; SQLite erlaubt jeweils nur eine schreibende Verbindung. Wird eine Verbindung mit einer unvollendeten Transaktion geschlossen, werden deren ausstehende Änderungen zurückgesetzt. Wenn eine Bibliothek automatisch eine Transaktion startet, muss das Programm deren Commit-Methode aufrufen, um die Änderungen zu übernehmen.

Eine fehlgeschlagene Anweisung hat nicht in jeder Datenbank dieselbe Wirkung. Du musst wissen, was noch aussteht, bevor du über die Fehlerbehebung entscheidest. Ein Sicherungspunkt kann innerhalb einer offenen Transaktion eine nähere Stelle für die Rückkehr bieten.

Einen Fehler nachvollziehen

Nach der Überweisung hat Maya 425,00 und Leo 195,00. Die Tabelle hat CHECK (balance >= 0). Starte eine Transaktion und ziehe 30,00 von Mayas Konto ab: Ihr noch nicht festgeschriebener Kontostand beträgt 395,00. Versuche dann, 300,00 von Leos Konto abzuziehen. Dadurch würde sein Kontostand −105,00 betragen, sodass die zweite Anweisung fehlschlägt.

Ein Festschreiben an dieser Stelle würde in SQLite nur Mayas Abzug übernehmen. In PostgreSQL beendet COMMIT die fehlgeschlagene Transaktion mit einem Rollback. Ein klarer Ablauf zur Fehlerbehebung ist, ROLLBACK auszuführen, die Ursache zu korrigieren und die zusammengehörigen Anweisungen erneut auszuführen. Beide Kontostände kehren dadurch vor dem korrigierten Versuch zu 425,00 und 195,00 zurück.

Einen späteren Teil mit einem Sicherungspunkt rückgängig machen

BEGIN;
UPDATE accounts SET balance = balance + 10 WHERE id = 1;
SAVEPOINT after_first;
UPDATE accounts SET balance = balance + 10 WHERE id = 2;
ROLLBACK TO after_first;
COMMIT;

Der Sicherungspunkt steht nach Mayas Erhöhung. ROLLBACK TO macht Leos spätere Erhöhung rückgängig, erhält aber die von Maya. Die endgültigen Kontostände betragen 435,00 und 195,00. Die Anweisung beendet die äußere Transaktion nicht; das tut COMMIT.

RELEASE after_first entfernt den Sicherungspunkt, ohne die danach vorgenommenen Änderungen rückgängig zu machen. Es ist kein eigenständiges dauerhaftes Festschreiben innerhalb der äußeren Transaktion. PostgreSQL erlaubt außerdem, mit ROLLBACK TO auf einen vor einem Fehler erstellten Sicherungspunkt den Fehlerzustand aufzuheben und von dort fortzufahren.

Prüfen, ob Strukturänderungen zurückgesetzt werden können

SQLite und PostgreSQL erlauben CREATE TABLE, ALTER TABLE und DROP TABLE innerhalb von Transaktionen. Zum Beispiel stellt BEGIN; DROP TABLE orders; ROLLBACK; die Tabelle und ihre Zeilen wieder her.

Gewöhnliche DDL-Anweisungen für dauerhafte Tabellen lösen in MySQL und Oracle implizite Commits aus. Ein CREATE TABLE, ALTER TABLE, DROP TABLE oder TRUNCATE TABLE kann neben seiner eigenen strukturellen Operation auch frühere ausstehende Änderungen festschreiben. Ein späteres Rollback kann diese frühere Arbeit nicht rückgängig machen. Geh nicht davon aus, dass eine Transaktion um ein Skript bewirkt, dass sich alle Datenbankdialekte gleich verhalten.

Beginne bei einer riskanten Datenänderung die Transaktion, führe den Schreibvorgang aus, prüfe seine Werte und die Anzahl und schreibe dann fest oder setze zurück. Prüfe zum Beispiel die Beleuchtungspreise nach UPDATE products SET price = ROUND(price * 1.10, 2) WHERE category = 'lighting';. Triff die Entscheidung zügig, damit die Transaktion andere Arbeiten nicht warten lässt.

ALTER TABLE ändert die Struktur einer bestehenden Tabelle und erhält ihre Zeilen. UPDATE ändert die Werte in diesen Zeilen. Das Hinzufügen eines Rabattfeldes braucht ALTER TABLE; das Erhöhen bereits gespeicherter Rabatte braucht UPDATE.

Felder hinzufügen und umbenennen

ALTER TABLE customers ADD COLUMN phone TEXT;
ALTER TABLE customers RENAME COLUMN phone TO mobile;
ALTER TABLE customers RENAME TO clients;

SQLite und PostgreSQL unterstützen diese Formen gleichermaßen. Eine neue Spalte gibt vorhandenen Zeilen ihren Standardwert oder NULL, wenn sie keinen hat. ADD COLUMN active INTEGER NOT NULL DEFAULT 1 gibt jeder vorhandenen Zeile für active den Wert 1. Das Hinzufügen von email TEXT NOT NULL ohne Standardwert schlägt bei einer gefüllten Tabelle fehl, weil den vorhandenen Zeilen ein erforderlicher Wert fehlen würde.

SQLite unterstützt RENAME COLUMN ab 3.25.0 und DROP COLUMN ab 3.35.0. Aktualisiere beim Umbenennen Anwendungscode und gespeicherte Abfragen, die auf den alten Namen verweisen. SQL außerhalb der Datenbank kann den neuen Namen nicht automatisch ermitteln.

Daten füllen, bevor sie vorgeschrieben werden

Füge in PostgreSQL eine Spalte hinzu, die NULL zulässt, fülle die vorhandenen Zeilen mit passenden Werten und schreibe den Wert erst dann vor:

ALTER TABLE customers ADD COLUMN email TEXT;
UPDATE customers SET email = 'unknown@example.com'
WHERE email IS NULL;
ALTER TABLE customers ALTER COLUMN email SET NOT NULL;

Dies zeigt das Füllen eines Pflichtfeldes; es deklariert die E-Mail-Adresse nicht als eindeutig. Eine echte eindeutige E-Mail-Spalte braucht unterschiedliche gültige Werte. SET NOT NULL schlägt fehl, wenn fehlende Werte verbleiben. PostgreSQL unterstützt auch das Ändern eines Typs mit ALTER COLUMN price TYPE NUMERIC(10, 2), das Setzen eines Standardwerts und das Hinzufügen einer benannten Prüfbedingung. Vorhandene Zeilen müssen eine neu hinzugefügte Regel erfüllen.

Ein Feld entfernen oder eine Tabelle neu aufbauen

ALTER TABLE customers DROP COLUMN mobile; entfernt das Feld und alle darin gespeicherten Werte. Abhängigkeiten können den Vorgang blockieren. SQLite lehnt das Entfernen einer Primärschlüssel-, eindeutigen, indizierten oder Fremdschlüsselspalte ab, ebenso einer Spalte, die von einem anderen Schemaobjekt verwendet wird. PostgreSQL kann abhängige Objekte mit CASCADE entfernen, darunter eine Sicht, die die Spalte verwendet.

SQLite kann mit einem einfachen ALTER weder den Typ einer bestehenden Spalte ändern noch Primärschlüssel-, Eindeutigkeits-, Fremdschlüssel- oder CHECK-Bedingungen zu bestehenden Spalten hinzufügen. Version 3.53.0 ergänzt ALTER COLUMN ... SET NOT NULL und DROP NOT NULL, aber keine allgemeine Bearbeitung von Integritätsbedingungen. Eine neu hinzugefügte Spalte kann eine Prüfbedingung oder einen erlaubten Verweis haben, aber kein PRIMARY KEY oder UNIQUE; bei eingeschalteter Fremdschlüsselprüfung benötigt ein hinzugefügter Verweis NULL als Standardwert.

Für eine umfassendere Änderung in SQLite:

1. Halte die Indizes, Trigger und Sichten fest, die erneut erstellt werden müssen. Sind Fremdschlüssel eingeschaltet, schalte sie vor der Transaktion aus.
2. Starte eine Transaktion und erstelle eine neue Tabelle mit den gewünschten Regeln.
3. Kopiere Zeilen mit ausdrücklichen Spaltenangaben in INSERT INTO new_products (...) SELECT ... FROM products;.
4. Entferne die alte Tabelle und benenne die neue in products um.
5. Erstelle abhängige Objekte erneut und führe PRAGMA foreign_key_check; aus. Behebe gemeldete Probleme vor dem Festschreiben.
6. Schreibe fest und schalte die Fremdschlüsselprüfung danach wieder ein, falls sie zuvor eingeschaltet war.

MySQL ändert Definitionen mit MODIFY COLUMN; SQL Server verwendet ALTER COLUMN. Übertrage eine Strukturänderung vor der Ausführung in die von der Zieldatenbank unterstützte Syntax.

DROP TABLE entfernt den Behälter ebenso wie seinen Inhalt. Nach DROP TABLE archived_orders; können Abfragen diese Tabelle nicht mehr lesen, weil sie nicht mehr existiert. Ihre Integritätsbedingungen, Indizes und Trigger werden mit ihr entfernt.

Den Umfang des Entfernens wählen

DROP TABLE IF EXISTS archived_orders; vermeidet einen Fehler, wenn die Tabelle nicht vorhanden ist. Eine vorhandene Tabelle und ihre Daten werden dennoch entfernt. Ein Einrichtungsskript, das Tabellen entfernt und erneut erstellt, zerstört Daten, wenn es auf einer Datenbank mit Datensätzen ausgeführt wird, die du behalten möchtest.

Verknüpfungen zwischen Tabellen beachten

Entferne Kindtabellen vor Elterntabellen, also in umgekehrter Reihenfolge zur üblichen Erstellung. In PostgreSQL schlägt das Entfernen von customers fehl, solange ein Fremdschlüssel einer Bestellung davon abhängt. DROP TABLE customers CASCADE; entfernt auch den abhängigen Fremdschlüssel und alle abhängigen Sichten. Die Bestelltabelle und ihre Zeilen bleiben bestehen, aber die Kundenbeziehung wird nicht mehr durchgesetzt.

Dieses PostgreSQL-CASCADE unterscheidet sich vom ON DELETE CASCADE eines Fremdschlüssels. Das erste entfernt abhängige Datenbankobjekte bei einer Strukturänderung. Das zweite entfernt Kindzeilen, wenn eine Elternzeile gelöscht wird. Wenn du weißt, welche Aktion verwendet wird, vermeidest du eine falsche Vorhersage über die verbleibenden Daten.

Bei eingeschalteter SQLite-Fremdschlüsselprüfung führt das Entfernen einer Tabelle zuerst eine implizite Löschung ihrer Zeilen aus. Verweisende Kindzeilen können dies blockieren. Deklariert die Beziehung ON DELETE CASCADE, können diese Kindzeilen gelöscht werden; SET NULL kann ihre Verknüpfungen aufheben. Beim Entfernen einer Tabelle musst du daher ebenso wie beim Löschen auf Verweise und zusätzlich auf die entfernte Tabellenstruktur achten.

Eine Wiederherstellung ermöglichen

Bewahre eine verwendbare Kopie auf, bevor du eine Tabelle mit echten Daten entfernst oder neu aufbaust. Eine schnelle interne Datenkopie ist:

CREATE TABLE products_backup AS
SELECT * FROM products;

In SQLite und PostgreSQL erhält dies die ausgewählten Daten, aber nicht die ursprünglichen Integritätsbedingungen. Es dient nicht als vollständige Rekonstruktion der Tabellendefinition. Ein Export oder eine Datenbanksicherung bewahrt Daten zur Wiederherstellung außerhalb der geänderten Tabelle auf.

SQLite und PostgreSQL erlauben auch, das Entfernen innerhalb einer Transaktion zu testen:

BEGIN;
DROP TABLE archived_orders;
ROLLBACK;

Das Rollback stellt die Tabelle und ihre Zeilen wieder her, weil das Entfernen nicht festgeschrieben wurde. Nach dem Festschreiben kann das Entfernen durch ein späteres ROLLBACK nicht rückgängig gemacht werden. In Datenbanken mit impliziten DDL-Commits bietet eine Transaktionssyntax um das Entfernen diese Möglichkeit zum Rückgängigmachen nicht. Prüfe die Zieldatenbank und die beteiligten Tabellen, bevor du ein Skript zum Neuaufbau ausführst.