Dokumentacja SQLite z przykładami: Widoki (views)

Q: Czym jest widok w SQLite?

Widok to zapisana instrukcja SELECT, którą możesz odpytywać jak tabelę. Nie przechowuje żadnych danych: przy każdym odczycie SQLite wykonuje zapytanie źródłowe od nowa. Widoki przydają się, żeby raz nazwać złożone zapytanie i używać go wszędzie albo żeby ukryć kolumny, których wywołujący nie powinni widzieć.

Q: Czy w SQLite można wykonać INSERT lub UPDATE przez widok?

Nie bezpośrednio. Widoki w SQLite są tylko do odczytu: INSERT, UPDATE i DELETE na widoku kończą się błędem. Możesz uczynić widok zapisywalnym, dołączając wyzwalacze INSTEAD OF, które tłumaczą zapis na operacje na tabelach źródłowych.

Q: Jak wyświetlić wszystkie widoki w bazie SQLite?

Odpytaj sqlitemaster: SELECT name FROM sqlitemaster WHERE type = 'view';. W CLI .schema pokazuje instrukcje CREATE VIEW, a .tables wyświetla widoki razem z tabelami.

Widoki w SQLite: CREATE VIEW, widoki tymczasowe i INSTEAD OF

Jak działają widoki w SQLite: zapisywanie zapytań jako wirtualnych tabel, kiedy używać widoków tymczasowych i dlaczego widoki w SQLite są domyślnie tylko do odczytu.

Na tej stronie są działające edytory: edytuj, uruchamiaj i od razu zobacz wynik.

Autor: Kevin Spektor, Współzałożyciel i CTO

Opublikowano May 3, 2026

Widok to zapisane zapytanie

Widok to instrukcja SELECT z nazwą. Gdy go utworzysz, możesz go odpytywać jak tabelę, ale nic nie jest przechowywane. Przy każdym odczycie z widoku SQLite wykonuje zapytanie źródłowe od nowa.

CREATE TABLE orders (
    id INTEGER PRIMARY KEY,
    customer TEXT,
    amount REAL,
    status TEXT
);

INSERT INTO orders (customer, amount, status) VALUES
    ('Ada', 120.00, 'paid'),
    ('Boris', 45.50, 'pending'),
    ('Rosa', 300.00, 'paid'),
    ('Boris', 80.00, 'paid');

CREATE VIEW paid_orders AS
SELECT customer, amount FROM orders WHERE status = 'paid';

SELECT * FROM paid_orders;

paid_orders wygląda i zachowuje się jak tabela. Ma kolumny, możesz z niego robić SELECT, możesz go łączyć z innymi tabelami. Ale pod spodem każde zapytanie rozwija się do oryginalnego filtra WHERE status = 'paid'.

To cały model myślowy: widok to alias dla zapytania.

Do czego przydają się widoki

Główna korzyść to nazwa. Skomplikowane zapytanie dostaje krótką, opisową nazwę, a reszta kodu pozostaje czytelna:

CREATE TABLE orders (
    id INTEGER PRIMARY KEY,
    customer TEXT,
    amount REAL,
    status TEXT
);

INSERT INTO orders (customer, amount, status) VALUES
    ('Ada', 120.00, 'paid'),
    ('Rosa', 300.00, 'paid'),
    ('Boris', 80.00, 'paid');

CREATE VIEW customer_totals AS
SELECT customer, SUM(amount) AS total, COUNT(*) AS order_count
FROM orders
WHERE status = 'paid'
GROUP BY customer;

SELECT * FROM customer_totals WHERE total > 100;

Bez widoku każdy wywołujący pisałby GROUP BY sam, a każdy z nich mógłby pomylić filtr. Z widokiem agregacja jest zdefiniowana raz. Wywołujący po prostu pytają o customer_totals i dodają na wierzchu dowolne dodatkowe filtry.

Widoki działają też jako granica w stylu uprawnień. Jeśli zapytanie nie powinno ujawniać kolumny password_hash, zbuduj widok, który wybiera wszystko oprócz tej kolumny, i każ kodowi aplikacji korzystać z widoku.

Składnia CREATE VIEW

Pełna forma:

CREATE [TEMPORARY] VIEW [IF NOT EXISTS] view_name [(column_aliases)] AS
SELECT ...;

Kilka rzeczy, które warto wiedzieć:

IF NOT EXISTS po cichu pomija tworzenie, jeśli widok już istnieje.
TEMPORARY (albo TEMP) tworzy widok, który znika po zamknięciu połączenia.
Aliasy kolumn w nawiasach pozwalają zmienić nazwy kolumn widoku bez ruszania źródłowego SELECT.

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

INSERT INTO products (name, price_cents) VALUES
    ('Notebook', 450),
    ('Pen', 200);

CREATE VIEW IF NOT EXISTS price_list (item, dollars) AS
SELECT name, price_cents / 100.0 FROM products;

SELECT * FROM price_list;

Widok udostępnia przyjaźniejsze nazwy (item, dollars) bez zmiany nazw kolumn w tabeli źródłowej.

Zastępowanie i usuwanie widoków

SQLite nie ma CREATE OR REPLACE VIEW ani ALTER VIEW. Aby zmienić definicję widoku, usuń go i utwórz ponownie:

CREATE TABLE orders (id INTEGER, status TEXT);
INSERT INTO orders VALUES (1, 'paid'), (2, 'pending');

CREATE VIEW active_orders AS
SELECT * FROM orders WHERE status = 'paid';

DROP VIEW active_orders;

CREATE VIEW active_orders AS
SELECT * FROM orders WHERE status IN ('paid', 'shipped');

SELECT * FROM active_orders;

DROP VIEW IF EXISTS active_orders; to bezpieczna forma: nie zgłosi błędu, jeśli widoku nie ma. Usunięcie widoku nigdy nie wpływa na tabele źródłowe; usuwasz tylko zapisane zapytanie.

Widoki tymczasowe

TEMP VIEW istnieje tylko dla bieżącego połączenia z bazą danych. Po zamknięciu połączenia widok znika. Przydaje się podczas doraźnych sesji analitycznych, po których nie chcesz zostawiać definicji:

CREATE TABLE events (
    id INTEGER PRIMARY KEY,
    type TEXT,
    occurred_at TEXT
);

INSERT INTO events (type, occurred_at) VALUES
    ('login', '2026-04-01'),
    ('purchase', '2026-04-01'),
    ('login', '2026-04-02');

CREATE TEMP VIEW today_logins AS
SELECT * FROM events WHERE type = 'login' AND occurred_at = '2026-04-02';

SELECT * FROM today_logins;

Widoki tymczasowe pozwalają też przesłonić nazwę zapytania bez utrwalania jej w schemacie, co jest wygodne podczas eksploracji danych.

Widoki są domyślnie tylko do odczytu

To najważniejsza pułapka. Nie możesz bezpośrednio wykonać INSERT, UPDATE ani DELETE przez widok:

sqlite> INSERT INTO paid_orders (customer, amount) VALUES ('Eve', 50);
Runtime error: cannot modify paid_orders because it is a view

Rozwiązaniem są wyzwalacze INSTEAD OF. Piszesz wyzwalacz, który uruchamia się zamiast próby zapisu i tłumaczy ją na prawdziwą operację na tabeli źródłowej:

CREATE TABLE orders (
    id INTEGER PRIMARY KEY,
    customer TEXT,
    amount REAL,
    status TEXT
);

CREATE VIEW paid_orders AS
SELECT id, customer, amount FROM orders WHERE status = 'paid';

CREATE TRIGGER paid_orders_insert
INSTEAD OF INSERT ON paid_orders
BEGIN
    INSERT INTO orders (customer, amount, status)
    VALUES (NEW.customer, NEW.amount, 'paid');
END;

INSERT INTO paid_orders (customer, amount) VALUES ('Eve', 50.00);

SELECT * FROM orders;

Widok pozostaje widokiem, ale zapisy do niego mają teraz dokąd trafić. Wyzwalacze omówimy porządnie na następnej stronie.

Brak widoków zmaterializowanych: zrób je sam

Niektóre bazy danych pozwalają zapisać wyniki widoku na dysku i odświeżać je na żądanie. SQLite tego nie potrafi. Każdy odczyt widoku wykonuje zapytanie źródłowe od nowa. Przy większości obciążeń to nie problem: SQLite jest szybki, a planista zapytań dobry. Przy kosztownych agregacjach odpytywanych wiele razy zbuduj prawdziwą tabelę i sam dbaj o jej synchronizację:

CREATE TABLE orders (
    id INTEGER PRIMARY KEY,
    customer TEXT,
    amount REAL
);

INSERT INTO orders (customer, amount) VALUES
    ('Ada', 120.00), ('Rosa', 300.00), ('Boris', 80.00);

CREATE TABLE customer_totals_cache AS
SELECT customer, SUM(amount) AS total
FROM orders
GROUP BY customer;

SELECT * FROM customer_totals_cache;

Potem odświeżasz pamięć podręczną według harmonogramu albo podpinasz wyzwalacze na orders, żeby była na bieżąco. To ręczna praca, ale w SQLite jedyna możliwość.

Wyświetlanie widoków

Metadane widoków są w sqlite_master razem z tabelami i indeksami:

CREATE TABLE t (x INTEGER);
CREATE VIEW v1 AS SELECT * FROM t;
CREATE VIEW v2 AS SELECT x * 2 AS doubled FROM t;

SELECT name, sql FROM sqlite_master WHERE type = 'view';

Kolumna sql zwraca oryginalną instrukcję CREATE VIEW, co przydaje się, gdy nie pamiętasz, co robi dany widok. W CLI .schema view_name wypisuje to samo w czytelniejszej formie.

Kiedy sięgać po widok

Widoki są warte zachodu, gdy:

Nietrywialne zapytanie jest używane w trzech lub więcej miejscach. Nazwanie go raz jest lepsze niż kopiowanie.
Chcesz udostępnić części aplikacji wyselekcjonowany podzbiór kolumn lub wierszy.
Agregacja jest pojęciowo jedną rzeczą (monthly_sales, active_users), którą wywołujący powinni traktować jak rzeczownik.

Odpuść widok, gdy:

Zapytanie jest używane dokładnie w jednym miejscu. Wpisz je bezpośrednio.
Liczy się wydajność, a zapytanie źródłowe jest kosztowne: płacisz ten koszt przy każdym odczycie. Zamiast tego zapisz wyniki w prawdziwej tabeli.
Widok zależy od innego widoku, który zależy od jeszcze innego. SQLite dobrze radzi sobie z zagnieżdżaniem, ale łańcuch trzech czy czterech widoków sprawia, że podczas debugowania trudno śledzić faktyczny SQL.

Dalej: wyzwalacze

Widoki i wyzwalacze często pojawiają się razem: wzorzec INSTEAD OF, który czyni widoki zapisywalnymi, to jeden z głównych powodów istnienia wyzwalaczy. Wyzwalacze przydają się też same w sobie do dzienników audytu, kaskadowych aktualizacji i pilnowania niezmienników. O tym jest następna strona.

Najczęściej zadawane pytania

Czym jest widok w SQLite?

Widok to zapisana instrukcja SELECT, którą możesz odpytywać jak tabelę. Nie przechowuje żadnych danych: przy każdym odczycie SQLite wykonuje zapytanie źródłowe od nowa. Widoki przydają się, żeby raz nazwać złożone zapytanie i używać go wszędzie albo żeby ukryć kolumny, których wywołujący nie powinni widzieć.

Czy w SQLite można wykonać INSERT lub UPDATE przez widok?

Nie bezpośrednio. Widoki w SQLite są tylko do odczytu: INSERT, UPDATE i DELETE na widoku kończą się błędem. Możesz uczynić widok zapisywalnym, dołączając wyzwalacze INSTEAD OF, które tłumaczą zapis na operacje na tabelach źródłowych.

Czy SQLite obsługuje widoki zmaterializowane?

Nie. SQLite ma tylko zwykłe (wirtualne) widoki: zapytanie wykonuje się przy każdym odczycie z widoku. Jeśli potrzebujesz zapamiętanych wyników, utwórz prawdziwą tabelę i odświeżaj ją samodzielnie albo użyj wyzwalacza, żeby synchronizować ją z tabelami źródłowymi.

Jak wyświetlić wszystkie widoki w bazie SQLite?

Odpytaj sqlite_master: SELECT name FROM sqlite_master WHERE type = 'view';. W CLI .schema pokazuje instrukcje CREATE VIEW, a .tables wyświetla widoki razem z tabelami.

Powiązane zagadnienia