Entwirf deine eigenen Tabellen mit passenden Typen und den Constraints NOT NULL, UNIQUE und PRIMARY KEY, die deine Daten schützen.
Diese Lektion in Kodokon öffnenBisher hast du fertige Tabellen abgefragt; ein professioneller Entwickler entwirft sie. Ein gutes Schema weist ungültige Daten schon beim Einfügen zurück: Es ist deine erste Verteidigungslinie, noch vor jedem Anwendungscode. Erstelle in sqliteonline.com oder sqlite3 diese Tabelle:
CREATE TABLE users (
id INTEGER PRIMARY KEY,
email TEXT NOT NULL UNIQUE,
username TEXT NOT NULL UNIQUE,
created_at TEXT NOT NULL
DEFAULT (datetime('now'))
);SQLite kennt nur fünf Speichertypen: INTEGER, REAL, TEXT, BLOB und NULL. Datumsangaben werden dort als TEXT im ISO-Format (2026-07-04) gespeichert. Anderswo (PostgreSQL, MySQL) würdest du stattdessen VARCHAR(255), TIMESTAMP oder BOOLEAN deklarieren: Das Prinzip bleibt gleich, nur die Typnamen ändern sich. Teste jetzt deine Constraints:
INSERT INTO users (email, username)
VALUES ('alice@example.com', 'alice');
INSERT INTO users (email, username)
VALUES ('alice@example.com', 'alice2');Der Primärschlüssel identifiziert jede Zeile: nie NULL, nie doppelt, nur einer pro Tabelle. In SQLite hat INTEGER PRIMARY KEY eine wertvolle Eigenschaft: Die Spalte zählt automatisch hoch, wenn du ihren Wert weglässt, wie in den Einfügungen oben. In PostgreSQL würdest du GENERATED ALWAYS AS IDENTITY schreiben, in MySQL AUTO_INCREMENT. Füge schließlich mit CHECK eine Geschäftsregel hinzu:
CREATE TABLE products (
id INTEGER PRIMARY KEY,
name TEXT NOT NULL,
sku TEXT NOT NULL UNIQUE,
price REAL NOT NULL CHECK (price >= 0)
);
INSERT INTO products (name, sku, price)
VALUES ('Keyboard', 'KB-01', -5);