CREATE TABLE w SQLite: składnia, ograniczenia i przykłady

CREATE TABLE definiuje schemat

Każdy fragment danych strukturalnych w SQLite żyje w tabeli, a każda tabela zaczyna się od instrukcji CREATE TABLE. Podajesz nazwę, wymieniasz kolumny i opcjonalnie dodajesz ograniczenia. SQLite zapisuje schemat w pliku bazy i tabela jest gotowa do użycia.

Najmniejszy użyteczny przykład:

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

INSERT INTO users (name, email) VALUES ('Ada', 'ada@example.com');
INSERT INTO users (name)        VALUES ('Boris');

SELECT * FROM users;

Trzy kolumny, jeden klucz główny, jedna reguła NOT NULL. SQLite automatycznie wypełnił id, bo to całkowitoliczbowy klucz główny, i pozwolił, żeby email w drugim wierszu było NULL, bo nic temu nie zabraniało. To cały kształt: nazwa, kolumny, ograniczenia. Wszystko inne na tej stronie to jego warianty.

Składnia kawałek po kawałku

Definicja kolumny to name TYPE constraint constraint .... W klasycznym SQLite typ jest opcjonalny (więcej o tym na stronie o type affinity), ale dobrą praktyką jest zawsze go podawać, bo polegają na nim czytelnicy i narzędzia.

CREATE TABLE products (
    id          INTEGER PRIMARY KEY,
    sku         TEXT    NOT NULL UNIQUE,
    name        TEXT    NOT NULL,
    price_cents INTEGER NOT NULL,
    in_stock    INTEGER NOT NULL DEFAULT 1
);

INSERT INTO products (sku, name, price_cents)
VALUES ('SKU-001', 'Notebook', 499);

SELECT * FROM products;

Kilka rzeczy, na które warto zwrócić uwagę:

• Ograniczenia łączy się spacjami: NOT NULL UNIQUE na sku oznacza, że obowiązują obie reguły.
• DEFAULT 1 na in_stock pozwala pominąć tę kolumnę w INSERT.
• SQLite używa INTEGER dla wartości logicznych, bo nie ma natywnego typu BOOLEAN. 0 to fałsz, 1 to prawda.
• Przecinek po ostatniej kolumnie to błąd składni. SQL jest tu bardziej rygorystyczny niż JavaScript.

IF NOT EXISTS: bez awarii przy ponownym uruchomieniu

Uruchom CREATE TABLE na bazie, która już ma tę tabelę, a SQLite zgłosi błąd:

Error: table users already exists

Za pierwszym razem to w porządku, za setnym irytuje. IF NOT EXISTS sprawia, że instrukcja nic nie robi, gdy tabela już istnieje:

CREATE TABLE IF NOT EXISTS users (
    id   INTEGER PRIMARY KEY,
    name TEXT NOT NULL
);

CREATE TABLE IF NOT EXISTS users (
    id   INTEGER PRIMARY KEY,
    name TEXT NOT NULL
);

SELECT name FROM sqlite_master WHERE type = 'table';

Drugie CREATE TABLE nic nie robi: bez błędu i bez zmiany schematu. To forma, której chcesz w kodzie startowym, skryptach migracji i wszędzie tam, gdzie ten sam SQL może się wykonać więcej niż raz.

Uwaga jednak: IF NOT EXISTS sprawdza tylko nazwę. Jeśli tabela o tej nazwie istnieje, ale ma inne kolumny, SQLite zostawia ją w spokoju. Nie "naprawi" ani nie "zaktualizuje" schematu za ciebie. Do tego służą migracje.

Ograniczenia: reguły, które podróżują ze schematem

Ograniczenia pozwalają przenieść walidację do samej bazy. Te, po które będziesz sięgać bez przerwy:

CREATE TABLE orders (
    id          INTEGER PRIMARY KEY,
    user_id     INTEGER NOT NULL,
    total_cents INTEGER NOT NULL CHECK (total_cents >= 0),
    status      TEXT    NOT NULL DEFAULT 'pending',
    created_at  TEXT    NOT NULL DEFAULT (datetime('now')),
    UNIQUE (user_id, created_at)
);

INSERT INTO orders (user_id, total_cents) VALUES (1, 1500);
INSERT INTO orders (user_id, total_cents, status) VALUES (1, 800, 'shipped');

SELECT * FROM orders;

• PRIMARY KEY: jednoznacznie identyfikuje wiersz. Więcej o tym w dokumencie o kluczach głównych.
• NOT NULL: kolumna musi mieć wartość.
• DEFAULT value: używane, gdy INSERT pomija kolumnę. Może to być literał albo wyrażenie, na przykład datetime('now').
• CHECK (expr): musi dawać prawdę dla każdego wiersza.
• UNIQUE (col, col): ograniczenie na poziomie tabeli, które wymusza unikalność kombinacji.

Ograniczenia działają przy każdym INSERT i UPDATE. Wiersz, który narusza któreś z nich, zostaje odrzucony, a instrukcja się nie udaje. Wyłapanie złych danych w bazie jest dużo tańsze niż wyłapywanie ich, gdy już rozejdą się po aplikacji.

Klucze obce

Klucz obcy mówi: "ta kolumna wskazuje na wiersz w innej tabeli". Utrzymuje spójność danych: nie możesz odwołać się do użytkownika, który nie istnieje, a (z odpowiednimi opcjami) usunięcie użytkownika może kaskadowo usunąć jego zamówienia.

PRAGMA foreign_keys = ON;

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

CREATE TABLE posts (
    id      INTEGER PRIMARY KEY,
    user_id INTEGER NOT NULL REFERENCES users(id) ON DELETE CASCADE,
    title   TEXT NOT NULL
);

INSERT INTO users (name) VALUES ('Ada');
INSERT INTO posts (user_id, title) VALUES (1, 'Hello, world');

SELECT p.id, u.name, p.title FROM posts p JOIN users u ON u.id = p.user_id;

Pułapka SQLite, którą warto zapamiętać: egzekwowanie kluczy obcych jest domyślnie wyłączone. Musisz uruchomić PRAGMA foreign_keys = ON w każdym połączeniu, w którym ograniczenia mają być sprawdzane. Większość sterowników aplikacyjnych robi to za ciebie albo udostępnia odpowiednie ustawienie. Jeśli twój nie, uruchom tę pragmę zaraz po połączeniu.

ON DELETE CASCADE oznacza tutaj, że usunięcie użytkownika automatycznie usuwa jego posty. Inne opcje to SET NULL, RESTRICT i domyślne NO ACTION, które odrzuca usunięcie, jeśli istnieją wiersze podrzędne.

CREATE TABLE AS SELECT

Czasem potrzebujesz szybkiej kopii wyniku zapytania jako nowej tabeli: na migawkę, kopię zapasową albo tabelę roboczą podczas analizy. Służy do tego CREATE TABLE ... AS SELECT:

CREATE TABLE products (
    id          INTEGER PRIMARY KEY,
    name        TEXT NOT NULL,
    price_cents INTEGER NOT NULL
);

INSERT INTO products (name, price_cents) VALUES
    ('Notebook', 499), ('Pen', 199), ('Stapler', 1299);

CREATE TABLE expensive_products AS
SELECT id, name, price_cents
FROM products
WHERE price_cents >= 500;

SELECT * FROM expensive_products;

Nowa tabela kopiuje nazwy kolumn, typy (w miarę możliwości) i dane. Równie ważne jest to, czego nie kopiuje: brak klucza głównego, brak NOT NULL, brak indeksów i kluczy obcych. To płaska migawka. Traktuj ją jako punkt wyjścia do doraźnej pracy, a nie sposób na klonowanie prawdziwego schematu.

Jeśli chcesz samą strukturę bez danych, dodaj WHERE 0:

CREATE TABLE products (
    id          INTEGER PRIMARY KEY,
    name        TEXT NOT NULL,
    price_cents INTEGER NOT NULL
);

CREATE TABLE products_archive AS SELECT * FROM products WHERE 0;

SELECT * FROM products_archive;
SELECT name FROM sqlite_master WHERE type = 'table';

Dostajesz pustą tabelę o tym samym kształcie kolumn, co przydaje się przy tabelach archiwalnych, które wypełnisz później.

Tabele tymczasowe

Tabela TEMP istnieje tylko w bieżącym połączeniu z bazą. Zamknij połączenie, a zniknie: bez sprzątania i bez pozostałości w schemacie:

CREATE TEMP TABLE recent_signups (
    user_id    INTEGER PRIMARY KEY,
    signed_up  TEXT NOT NULL
);

INSERT INTO recent_signups VALUES (1, '2026-01-15'), (2, '2026-01-18');

SELECT * FROM recent_signups;

Dobre zastosowania: przechowywanie wierszy dla wieloetapowego zapytania, trzymanie wyników pośrednich zbyt zawiłych na CTE, izolowanie danych jednego połączenia w długiej sesji. CREATE TEMP TABLE i CREATE TEMPORARY TABLE znaczą to samo.

Możesz to też łączyć z AS SELECT: CREATE TEMP TABLE snapshot AS SELECT ... to popularny wzorzec zamrażania zbioru wyników w trakcie analizy.

Cytowanie nazw

Zwykle nazwy kolumn i tabel to zwykłe identyfikatory. Jeśli musisz użyć słowa zastrzeżonego albo nazwy ze spacjami, otocz ją cudzysłowami (standard SQL) albo grawisami (zwyczaj z MySQL, który SQLite też akceptuje):

CREATE TABLE "order" (
    id        INTEGER PRIMARY KEY,
    "select"  TEXT,
    "user id" INTEGER
);

INSERT INTO "order" ("select", "user id") VALUES ('a', 1);
SELECT * FROM "order";

Działa, ale przy każdym odwołaniu do tabeli jest to utrudnienie. Wybieraj zwykłe nazwy, takie jak orders, selection, user_id, i w ogóle unikaj cytowania.

Realistyczny przykład

Składając wszystko razem: mały schemat aplikacji do zadań z IF NOT EXISTS, żeby mógł się wykonywać przy każdym starcie:

PRAGMA foreign_keys = ON;

CREATE TABLE IF NOT EXISTS users (
    id    INTEGER PRIMARY KEY,
    email TEXT NOT NULL UNIQUE,
    name  TEXT NOT NULL
);

CREATE TABLE IF NOT EXISTS tasks (
    id          INTEGER PRIMARY KEY,
    user_id     INTEGER NOT NULL REFERENCES users(id) ON DELETE CASCADE,
    title       TEXT    NOT NULL,
    done        INTEGER NOT NULL DEFAULT 0 CHECK (done IN (0, 1)),
    created_at  TEXT    NOT NULL DEFAULT (datetime('now'))
);

INSERT INTO users (email, name) VALUES ('ada@example.com', 'Ada');
INSERT INTO tasks (user_id, title) VALUES (1, 'Write the docs');

SELECT u.name, t.title, t.done FROM tasks t JOIN users u ON u.id = t.user_id;

To schemat, który można wdrożyć: idempotentne tworzenie, egzekwowane klucze obce, CHECK pilnujący, żeby done miało sensowną wartość, rozsądne wartości domyślne i znaczniki czasu, które wypełniają się same.

Dalej: typy danych

CREATE TABLE pozwala pisać INTEGER, TEXT, REAL, ale SQLite słynie z luźnego podejścia do przechowywania tych wartości. Następna strona omawia pięć klas przechowywania, których SQLite naprawdę używa, i wyjaśnia, dlaczego zadeklarowany typ nie zawsze jest typem, który dostajesz.