SQLite: DROP TABLE und ALTER TABLE richtig nutzen

Schemas ändern sich. SQLite macht das mit – meistens.

Sobald eine Tabelle existiert, willst du sie früher oder später umbenennen, eine Spalte hinzufügen, eine Spalte entfernen oder die ganze Struktur umbauen. SQLite deckt die typischen Fälle direkt mit DROP TABLE und ALTER TABLE ab und bietet für alles andere einen dokumentierten Workaround.

Der Haken: ALTER TABLE ist in SQLite deutlich eingeschränkter als in Postgres oder MySQL. Zu wissen, was geht und was nicht – und welches Rebuild-Muster bei den Nicht-Geht-Fällen greift – macht hier den Großteil des Know-hows aus.

SQLite-Tabelle löschen mit DROP TABLE

DROP TABLE entfernt die Tabelle samt aller Zeilen, Indizes und der darauf definierten Trigger. Ein Undo gibt es nicht:

CREATE TABLE scratch (
    id INTEGER PRIMARY KEY,
    note TEXT
);

INSERT INTO scratch (note) VALUES ('vorübergehend'), ('auch vorübergehend');

DROP TABLE scratch;

SELECT name FROM sqlite_master WHERE type = 'table';

Damit ist die Tabelle weg. Eine Abfrage darauf würde jetzt den Fehler no such table: scratch werfen.

Wenn du dir nicht sicher bist, ob die Tabelle überhaupt existiert – typischer Fall in Setup-Skripten –, hängst du einfach IF EXISTS an. Dann passiert stillschweigend nichts, falls die Tabelle fehlt:

CREATE TABLE scratch (id INTEGER PRIMARY KEY);

DROP TABLE IF EXISTS scratch;
DROP TABLE IF EXISTS scratch;
SELECT 'beide DROP-Anweisungen erfolgreich' AS result;

Ohne IF EXISTS würde der zweite DROP einen Fehler werfen. Mit der Klausel laufen beide sauber durch.

Fremdschlüssel können ein DROP blockieren

Wenn die Fremdschlüssel-Prüfung aktiv ist (PRAGMA foreign_keys = ON;) und eine andere Tabelle auf die zu löschende Tabelle verweist, schlägt das Löschen fehl:

sqlite> PRAGMA foreign_keys = ON;
sqlite> DROP TABLE users;
Runtime error: FOREIGN KEY constraint failed

Du hast mehrere Möglichkeiten: die referenzierende Tabelle zuerst löschen, die referenzierenden Zeilen entfernen oder den Foreign Key gleich beim Anlegen mit ON DELETE CASCADE definieren. SQLite wird die referentielle Integrität nicht stillschweigend aushebeln.

ALTER TABLE: Die vier möglichen Operationen

ALTER TABLE in SQLite unterstützt genau vier Operationen:

CREATE TABLE posts (
    id INTEGER PRIMARY KEY,
    title TEXT NOT NULL,
    body TEXT
);

-- 1. Tabelle umbenennen
ALTER TABLE posts RENAME TO articles;

-- 2. Spalte umbenennen
ALTER TABLE articles RENAME COLUMN body TO content;

-- 3. Spalte hinzufügen
ALTER TABLE articles ADD COLUMN published_at TEXT;

-- 4. Spalte entfernen (SQLite 3.35+)
ALTER TABLE articles DROP COLUMN published_at;

SELECT sql FROM sqlite_master WHERE name = 'articles';

Jede dieser Anweisungen läuft als einzelnes Statement. Die ersten beiden sind praktisch kostenlos – sie passen lediglich das Schema an. Auch ADD COLUMN geht flott: SQLite schreibt die Tabelle nicht neu, sondern vermerkt nur die neue Spaltendefinition. DROP COLUMN ist hingegen aufwendiger – hier muss SQLite jede Zeile neu schreiben, um die Daten der Spalte tatsächlich zu entfernen.

SQLite ALTER TABLE ADD COLUMN mit Standardwert

Wenn du in SQLite eine Spalte zu einer bestehenden Tabelle hinzufügst, ist sie für alle vorhandenen Zeilen zunächst NULL – es sei denn, du legst einen Default-Wert fest:

CREATE TABLE users (
    id INTEGER PRIMARY KEY,
    email TEXT NOT NULL
);

INSERT INTO users (email) VALUES ('ada@example.com'), ('boris@example.com');

ALTER TABLE users ADD COLUMN status TEXT NOT NULL DEFAULT 'active';

SELECT * FROM users;

Beide bestehenden Zeilen bekommen 'active' eingetragen. Der Default muss eine Konstante sein – SQLite akzeptiert weder CURRENT_TIMESTAMP noch irgendeinen anderen nicht-konstanten Ausdruck als Default bei ADD COLUMN. Der Grund: Es braucht einen Wert, der sich auf alle vorhandenen Zeilen anwenden lässt, ohne pro Zeile neu ausgewertet zu werden.

Wenn du NOT NULL ohne Default brauchst, musst du die Spalte zunächst als nullable hinzufügen, sie per UPDATE befüllen und anschließend die Tabelle neu aufbauen, um das Constraint zu setzen. Damit sind wir auch schon bei den Grenzen von ALTER TABLE.

Was ALTER TABLE in SQLite nicht kann

Dinge, die in Postgres oder MySQL funktionieren, in SQLite aber nicht:

• Den Datentyp einer Spalte ändern (ALTER COLUMN ... TYPE ...).
• Den Default einer Spalte direkt ändern.
• NOT NULL, CHECK, UNIQUE oder PRIMARY KEY an einer bestehenden Spalte hinzufügen oder entfernen.
• Einen Foreign Key auf eine bestehende Spalte legen.
• Spalten umsortieren.

Jeder dieser Versuche endet mit einem Syntaxfehler. Eine ALTER COLUMN-Klausel gibt es in SQLite schlicht nicht. Die offizielle Antwort ist in allen Fällen dieselbe: Tabelle neu aufbauen.

Das Rebuild-Pattern

Wenn ALTER TABLE nicht weiterhilft, legst du eine neue Tabelle mit dem gewünschten Schema an, kopierst die Daten rüber, löschst die alte und benennst die neue um. Pack das Ganze in eine Transaktion, damit es entweder komplett klappt oder gar nicht:

CREATE TABLE users (
    id INTEGER PRIMARY KEY,
    email TEXT,
    age TEXT
);

INSERT INTO users (email, age) VALUES ('ada@example.com', '36'), ('boris@example.com', '41');

BEGIN;

CREATE TABLE users_new (
    id INTEGER PRIMARY KEY,
    email TEXT NOT NULL,
    age INTEGER CHECK (age > 0)
);

INSERT INTO users_new (id, email, age)
SELECT id, email, CAST(age AS INTEGER) FROM users;

DROP TABLE users;
ALTER TABLE users_new RENAME TO users;

COMMIT;

SELECT * FROM users;

Jetzt ist users.age eine Ganzzahl mit Check-Constraint und email ist NOT NULL. Die Daten sind beim Umbau einfach mitgewandert.

Ein paar Dinge, die du in der Praxis beachten solltest:

• Foreign Keys vorher abschalten. Wenn andere Tabellen auf deine verweisen, setze PRAGMA foreign_keys = OFF; vor der Transaktion und PRAGMA foreign_keys = ON; danach. Sonst scheitert das DROP TABLE. Das Pragma lässt sich innerhalb einer Transaktion nicht ändern – also unbedingt außerhalb setzen.
• Indizes und Trigger neu anlegen. Mit der alten Tabelle verschwinden auch deren Indizes und Trigger. Lege sie nach dem Umbenennen wieder auf der neuen Tabelle an.
• Views prüfen. Views, die auf die Tabelle verweisen, zeigen in ihrem gespeicherten SQL noch auf den alten Namen. Alles, was auf geänderte Spalten zugreift, musst du neu aufbauen.

Das Rebuild-Muster ist umständlich, aber zuverlässig. Genau so machen es Migrations-Tools wie Alembic oder Rails intern, wenn sie auf SQLite arbeiten.

Mehrere Tabellen löschen in SQLite

Es gibt kein einzelnes Statement, um mehrere Tabellen auf einmal zu löschen – du führst DROP TABLE einfach pro Tabelle aus. In einer Transaktion, wenn du sie als Einheit zusammenfassen möchtest:

CREATE TABLE a (id INTEGER);
CREATE TABLE b (id INTEGER);
CREATE TABLE c (id INTEGER);

BEGIN;
DROP TABLE a;
DROP TABLE b;
DROP TABLE c;
COMMIT;

SELECT name FROM sqlite_master WHERE type = 'table';

Wenn man die drei Drops in eine Transaktion packt, gilt das Alles-oder-nichts-Prinzip – entweder funktionieren alle drei oder keiner. Praktisch ist das vor allem dann, wenn man zusammenhängende Tabellen abräumen will, die unterwegs an Foreign Keys scheitern könnten.

Was du mitnimmst

• DROP TABLE entfernt eine Tabelle samt zugehöriger Indizes und Trigger. Für idempotente Skripte nimmst du DROP TABLE IF EXISTS.
• ALTER TABLE in SQLite kann genau vier Dinge: Tabelle umbenennen, Spalte umbenennen, Spalte hinzufügen, Spalte löschen.
• Für alles andere – Typänderungen, neue Constraints, Foreign Keys auf bestehenden Spalten – baust du die Tabelle innerhalb einer Transaktion neu auf.
• Achte beim Neuaufbau auf Foreign Keys, Indizes, Trigger und Views. Die wandern nicht automatisch mit den Daten mit.

Als Nächstes: Daten einfügen

Ein ganzes Kapitel lang ging es um Tabellen und die Constraints, die ihnen Form geben. Jetzt wird es Zeit, sie auch zu befüllen – das nächste Kapitel startet mit INSERT, inklusive der Mehrzeilen-Variante, Default-Werten und der Frage, wie SQLite mit Inserts umgeht, die deine Constraints verletzen.