Views ב-SQLite: CREATE VIEW, Views זמניים ו-INSTEAD OF

View הוא שאילתה שמורה

View הוא פקודת SELECT עם שם. אחרי שיצרתם אחד, אפשר לשאול אותו כמו טבלה, אבל שום דבר לא נשמר. בכל פעם שקוראים מ-view, SQLite מריץ את השאילתה שמתחתיו מחדש.

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 נראה ומתנהג כמו טבלה. יש לו עמודות, אפשר לבצע עליו SELECT, אפשר לעשות איתו join. אבל מתחת למכסה המנוע, כל שאילתה נפרשת לסינון המקורי WHERE status = 'paid'.

זה כל המודל המנטלי: view הוא כינוי לשאילתה.

למה Views שימושיים

היתרון העיקרי הוא מתן שם. שאילתה מסובכת מקבלת שם קצר ותיאורי, ושאר הקוד שלכם נשאר קריא:

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;

בלי ה-view, כל קוד קורא היה כותב את ה-GROUP BY בעצמו, וכל אחד מהם היה יכול לטעות בסינון. איתו, הצבירה מוגדרת פעם אחת. הקוראים פשוט מבקשים את customer_totals ומוסיפים מעליו כל סינון נוסף שהם צריכים.

Views עובדים גם כגבול בסגנון הרשאות. אם שאילתה לא אמורה לחשוף עמודת password_hash, בנו view שבוחר הכול חוץ מהעמודה הזו, ותנו לקוד האפליקציה להשתמש ב-view.

התחביר של CREATE VIEW

הצורה המלאה:

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

כמה דברים שכדאי לדעת:

• IF NOT EXISTS מדלג בשקט על היצירה אם ה-view כבר קיים.
• TEMPORARY (או TEMP) יוצר view שנעלם כשהחיבור נסגר.
• כינויי עמודות בסוגריים מאפשרים לשנות את שמות העמודות של ה-view בלי לגעת ב-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;

ה-view חושף שמות ידידותיים יותר (item, dollars) בלי לשנות את שמות העמודות בטבלת המקור.

החלפה ומחיקה של Views

ל-SQLite אין CREATE OR REPLACE VIEW או ALTER VIEW. כדי לשנות את ההגדרה של view, מחקו אותו וצרו אותו מחדש:

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; היא הצורה הבטוחה: היא לא תיכשל אם ה-view לא קיים. מחיקת view אף פעם לא משפיעה על הטבלאות שמתחתיו: אתם מוחקים רק את השאילתה השמורה.

Views זמניים

TEMP VIEW קיים רק עבור החיבור הנוכחי למסד הנתונים. כשהחיבור נסגר, ה-view נעלם. שימושי לסשנים של ניתוח אד הוק שבהם אתם לא רוצים להשאיר הגדרות מאחור:

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;

Views זמניים גם מאפשרים לתת לשאילתה שם זמני, אפילו כזה שמסתיר שם קיים, בלי להתחייב אליו בסכמה, וזה נוח בזמן חקירה.

Views הם לקריאה בלבד כברירת מחדל

זו המלכודת החשובה ביותר. אי אפשר לבצע INSERT, UPDATE או DELETE דרך view ישירות:

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

הפתרון הוא טריגרים של INSTEAD OF. כותבים טריגר שמופעל במקום ניסיון הכתיבה ומתרגם אותו לפעולה אמיתית על הטבלה שמתחת:

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;

ה-view נשאר view, אבל לכתיבות אליו יש עכשיו לאן ללכת. נכסה טריגרים כמו שצריך בדף הבא.

אין Materialized Views: בנו בעצמכם

חלק ממסדי הנתונים מאפשרים לשמור את התוצאות של view על הדיסק ולרענן אותן לפי דרישה. SQLite לא. כל קריאה מ-view מריצה מחדש את השאילתה שמתחתיו. לרוב העומסים זה בסדר: SQLite מהיר ומתכנן השאילתות טוב. לצבירות יקרות שנשאלות פעמים רבות, בנו טבלה אמיתית ושמרו אותה מסונכרנת בעצמכם:

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;

אחר כך תרעננו את המטמון לפי לוח זמנים, או תחברו טריגרים על orders כדי לשמור אותו עדכני. זו עבודה ידנית, אבל זו גם האפשרות היחידה ב-SQLite.

הצגת Views

המטא דאטה של views נשמר ב-sqlite_master לצד טבלאות ואינדקסים:

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';

העמודה sql מחזירה את פקודת ה-CREATE VIEW המקורית: שימושי כששכחתם מה view עושה. ב-CLI, .schema view_name מדפיס את אותו הדבר בצורה נקייה יותר.

מתי לפנות ל-View

Views מצדיקים את עצמם כאשר:

• שאילתה לא טריוויאלית נמצאת בשימוש בשלושה מקומות או יותר. לתת לה שם פעם אחת עדיף על העתקה והדבקה.
• רוצים לחשוף תת קבוצה מוקפדת של עמודות או שורות לחלק מהאפליקציה.
• צבירה היא מבחינה רעיונית דבר אחד (monthly_sales, active_users) שהקוראים צריכים להתייחס אליו כשם עצם.

וותרו על ה-view כאשר:

• השאילתה משמשת במקום אחד בדיוק. כתבו אותה ישירות.
• הביצועים חשובים והשאילתה שמתחת יקרה: אתם משלמים את המחיר הזה בכל קריאה. שמרו במקום זאת במטמון בטבלה אמיתית.
• ה-view תלוי ב-view אחר שתלוי ב-view אחר. SQLite מטפל בקינון היטב, אבל שרשרת של שלושה או ארבעה views הופכת את ה-SQL האמיתי לקשה למעקב בזמן דיבוג.

הבא בתור: טריגרים

Views וטריגרים מופיעים יחד הרבה: תבנית ה-INSTEAD OF שמאפשרת לכתוב ל-views היא אחת הסיבות העיקריות לקיומם של טריגרים. טריגרים שימושיים גם בפני עצמם ליומני ביקורת, לעדכונים מתגלגלים ולאכיפת אינווריאנטים. זה הדף הבא.