SQLite Datentypen: Storage Classes & dynamische Typisierung

Fünf Storage Classes statt vieler Datentypen

SQLite speichert jeden Wert in einer von fünf Storage Classes:

• NULL — kein Wert vorhanden.
• INTEGER — eine vorzeichenbehaftete Ganzzahl, je nach Größe 1 bis 8 Bytes.
• REAL — eine 8-Byte-Fließkommazahl nach IEEE-Standard.
• TEXT — eine Zeichenkette, gespeichert in der Kodierung der Datenbank (meist UTF-8).
• BLOB — rohe Bytes, exakt so abgelegt, wie du sie übergeben hast.

Mehr gibt es nicht. Kein eigenes BOOLEAN, kein DATETIME, kein VARCHAR, kein DECIMAL. Während andere Datenbanken Dutzende von Typen mitbringen, kommt SQLite mit fünf aus — alles Weitere baut darauf auf.

CREATE TABLE samples (
    a INTEGER,
    b REAL,
    c TEXT,
    d BLOB
);

INSERT INTO samples VALUES (42, 3.14, 'hallo', x'deadbeef');

SELECT a, typeof(a), b, typeof(b), c, typeof(c), d, typeof(d)
FROM samples;

typeof() zeigt dir die tatsächliche Storage Class jedes Werts an. Du bekommst integer, real, text oder blob zu sehen. Diese vier – plus null – sind alles, was SQLite kennt.

SQLite dynamische Typisierung

Jetzt kommt der Teil, der Umsteiger von Postgres oder MySQL gerne mal aus der Bahn wirft. In SQLite (ohne STRICT) ist der Typ, den du an einer Spalte deklarierst, eher ein Vorschlag als ein verbindlicher Vertrag. Der eigentliche Typ klebt am jeweiligen Wert:

CREATE TABLE notes (
    id   INTEGER,
    body TEXT
);

INSERT INTO notes VALUES (1, 'eine echte Notiz');
INSERT INTO notes VALUES ('zwei', 12345);

SELECT id, typeof(id), body, typeof(body) FROM notes;

Beide Zeilen wurden akzeptiert. Die Spalte id enthält in einer Zeile einen Integer und in der anderen Text; body hält einmal Text und einmal einen Integer. SQLite speichert Werte jeder Storage Class problemlos in jeder Spalte.

Das ist die dynamische Typisierung von SQLite – eine bewusste Designentscheidung. Sie macht SQLite angenehm nachsichtig, wenn du schnell prototypisierst oder kleine Skripte schreibst. Gleichzeitig kann ein Tippfehler in deinem Anwendungscode dazu führen, dass jahrelang Daten in der falschen Form abgelegt werden, ohne dass es jemand merkt. Wenn dich dieser Kompromiss stört – und bei den meisten produktiven Schemata sollte er das – sind STRICT Tables die Lösung. Dazu kommen wir gleich.

Type Affinity – kurz erklärt

Der deklarierte Typ einer Spalte wird keineswegs ignoriert; er gibt der Spalte eine sogenannte Affinity. Beim Einfügen versucht SQLite, den Wert in Richtung dieser Affinity zu konvertieren, sofern eine verlustfreie Umwandlung möglich ist. Eine TEXT-Spalte, die die Zahl 42 bekommt, behält sie als Text '42'; eine INTEGER-Spalte, die den String '42' erhält, speichert ihn als Integer 42. Würde die Konvertierung Informationen verlieren, bleibt der ursprüngliche Typ erhalten.

CREATE TABLE prices (
    label TEXT,
    cents INTEGER
);

INSERT INTO prices VALUES (42, '100');
INSERT INTO prices VALUES ('coffee', '3.5');

SELECT label, typeof(label), cents, typeof(cents) FROM prices;

Erste Zeile: Die Ganzzahl 42 wurde zu Text '42' umgewandelt, und der String '100' wurde zur Ganzzahl 100. Zweite Zeile: '3.5' ließ sich nicht verlustfrei in INTEGER umwandeln und blieb deshalb als Text erhalten. Dem Thema Type Affinity widmen wir gleich eine eigene Seite — für den Moment reicht es zu wissen, dass der Spaltentyp die Speicherung zwar beeinflusst, aber nicht erzwingt.

Boolean-Werte in SQLite speichern

Eine eigene Storage Class BOOLEAN gibt es in SQLite nicht. Boolesche Werte werden stattdessen als Ganzzahlen abgelegt — 0 für false, 1 für true:

CREATE TABLE tasks (
    title TEXT,
    done  BOOLEAN
);

INSERT INTO tasks VALUES ('Doku schreiben', TRUE);
INSERT INTO tasks VALUES ('Ausliefern', FALSE);

SELECT title, done, typeof(done) FROM tasks
WHERE done = 1;

Die Schlüsselwörter TRUE und FALSE werden seit SQLite 3.23 erkannt und intern zu 1 bzw. 0 übersetzt. Eine Spaltendeklaration als BOOLEAN verleiht der Spalte numerische Affinität, schränkt sie aber nicht auf 0/1 ein – ohne STRICT lässt sich problemlos 'maybe' einfügen, und SQLite mault nicht.

Datum und Uhrzeit in SQLite

Einen eigenen Typ DATETIME gibt es ebenfalls nicht. Du entscheidest dich für eine von drei Kodierungen, und die Datumsfunktionen von SQLite kommen mit allen dreien klar:

• TEXT im ISO-8601-Format: '2026-04-23 14:30:00'.
• REAL als julianische Tageszahl.
• INTEGER als Unix-Zeitstempel in Sekunden.

CREATE TABLE events (
    name      TEXT,
    happened  TEXT
);

INSERT INTO events VALUES ('Start', '2026-04-23 09:00:00');
INSERT INTO events VALUES ('Demo',  datetime('now'));

SELECT name, happened, date(happened), strftime('%H:%M', happened)
FROM events;

ISO-8601 als Text ist die gängigste Wahl – die Sortierung funktioniert als String korrekt, es ist menschenlesbar, und die eingebauten Funktionen (date(), time(), datetime(), strftime(), julianday()) kommen alle damit klar. Entscheide dich pro Spalte für ein Format und bleib dabei; gemischte Formate in derselben Spalte sind genau die Sorte Problem, die dich ein halbes Jahr später einholt.

VARCHAR, CHAR und andere bekannte Typnamen

SQLite akzeptiert auch die Typnamen, die du aus anderen Datenbanken kennst – VARCHAR(255), CHAR(10), NVARCHAR, DECIMAL(10,2), DOUBLE, FLOAT, INT, BIGINT, MEDIUMINT. Alle werden problemlos geparst. Sie werden lediglich über die Affinitätsregeln auf eine der fünf Storage Classes abgebildet.

CREATE TABLE users (
    id        BIGINT,
    name      VARCHAR(255),
    bio       NVARCHAR(2000),
    balance   DECIMAL(10, 2)
);

INSERT INTO users VALUES (1, 'Ada', 'Erfinderin', 99.50);

SELECT typeof(id), typeof(name), typeof(bio), typeof(balance) FROM users;

VARCHAR(255) erzwingt kein 255-Zeichen-Limit — SQLite ignoriert die Längenangabe schlicht. DECIMAL(10, 2) speichert keine Dezimalzahl mit fester Genauigkeit, sondern erhält numerische Affinität und landet intern als INTEGER oder REAL. Diese Namen existieren nur, damit Schemas aus anderen Datenbanken ohne Anpassung laufen; die Einschränkungen, die anderswo dahinterstehen, bringen sie nicht mit.

Wer für Geldbeträge exakte Dezimalarithmetik braucht, speichert die Beträge als Cent in einem INTEGER-Feld. Bei REAL schleichen sich Fließkomma-Rundungsfehler früher oder später ab der dritten Nachkommastelle ein.

NULL ist eine eigene Storage Class

NULL ist in SQLite nicht einfach „kein Wert", sondern selbst ein Wert mit eigener Storage Class — typeof() gibt das auch genau so zurück:

CREATE TABLE optional (
    a INTEGER,
    b TEXT
);

INSERT INTO optional (a) VALUES (5);

SELECT a, typeof(a), b, typeof(b) FROM optional;

b taucht als null auf. Das ist wichtig, denn NULL ist mit nichts gleich — nicht einmal mit einem anderen NULL. b = NULL ist also nie wahr; man muss b IS NULL schreiben. Darauf gehen wir später im Kapitel zu Operatoren und NULL genauer ein, aber der Ursprung liegt hier, bei der Storage Class.

Rohdaten speichern mit BLOB

BLOB legt rohe Bytes 1:1 ab — praktisch für kleine Bilder, Hashes, kodierte Daten oder alles, was weder Text noch Zahl ist:

CREATE TABLE files (
    name  TEXT,
    data  BLOB
);

INSERT INTO files VALUES ('signature', x'89504e470d0a1a0a');

SELECT name, length(data), hex(data), typeof(data) FROM files;

Mit dem Literal x'...' kannst du Blobs in SQL als Hex-Werte schreiben; aus dem Anwendungscode heraus übergibst du normalerweise ein Byte-Array über einen Parameter. length() liefert bei einem Blob die Anzahl der Bytes zurück, nicht die Anzahl der Zeichen.

Ein Hinweis aus der Praxis: SQLite speichert auch große Blobs problemlos, aber wenn du bei jeder Abfrage, die die Zeile berührt, einen 50-MB-Blob mitziehst, wird das richtig langsam. Bei großen Dateien legst du die Datei besser auf der Festplatte ab und speicherst nur den Pfad in der Datenbank.

Was du mitnimmst

• Fünf Storage Classes — NULL, INTEGER, REAL, TEXT, BLOB — decken alles ab.
• Booleans sind Integer; Datumswerte speicherst du als Text, Real oder Integer — du entscheidest.
• Deklarierte Spaltentypen sind Hinweise, keine festen Verträge (es sei denn, du verwendest STRICT).
• VARCHAR(255) und Konsorten werden zwar geparst, aber die Länge oder Genauigkeit, die sie andernorts suggerieren, wird nicht erzwungen.
• typeof(value) ist dein bester Freund, wenn du dir nicht sicher bist, was tatsächlich in der Spalte steckt.

Als Nächstes: Type Affinity

Hinter dem „Hinweis"-Verhalten, das wir hier nur angerissen haben, steckt ein klares Regelwerk — fünf Affinitätsklassen, abgeleitet aus dem deklarierten Typnamen, die bei jedem Insert greifen. Genau darum geht es auf der nächsten Seite, und das ist der Schlüssel dazu, vorherzusagen, was SQLite mit deinen Werten wirklich anstellt.