الأعمدة المُولَّدة في SQLite: VIRTUAL مقابل STORED

العمود المُولَّد هو عمود محسوب

العمود المُولَّد (Generated Column) في SQLite هو عمود تأتي قيمته من تعبير حسابي، لا من جملة INSERT. تكتب الصيغة مرة واحدة داخل CREATE TABLE، وبعدها SQLite يتكفّل بالباقي. لا يمكنك الكتابة إلى هذا العمود إطلاقًا، وأي محاولة لذلك ستُرجع خطأ.

إليك أبسط مثال ممكن:

CREATE TABLE products (
    id      INTEGER PRIMARY KEY,
    price   REAL NOT NULL,
    tax     REAL NOT NULL,
    total   REAL GENERATED ALWAYS AS (price + tax)
);

INSERT INTO products (price, tax) VALUES (100.0, 8.5);
INSERT INTO products (price, tax) VALUES (49.99, 4.25);

SELECT id, price, tax, total FROM products;

total لم يتم إدخاله أبداً، ومع ذلك يظهر في كل صف. فـ SQLite يعيد حسابه من price + tax في كل مرة تقرأ فيها الصف. حدِّث أيّاً من العمودين وسيتبعه total تلقائياً.

عبارة GENERATED ALWAYS AS إلزامية. وكلمة ALWAYS هي مجرد صيغة شكلية من معيار SQL — لا يوجد خيار آخر في SQLite أصلاً.

الفرق بين VIRTUAL و STORED في SQLite

كل عمود مُولَّد لا بد أن يكون من أحد نوعَين. والنوع الافتراضي هو VIRTUAL:

CREATE TABLE orders (
    id        INTEGER PRIMARY KEY,
    qty       INTEGER NOT NULL,
    unit      REAL NOT NULL,
    -- يُعاد حسابه عند كل SELECT
    subtotal  REAL GENERATED ALWAYS AS (qty * unit) VIRTUAL,
    -- يُحسب مرة واحدة ويُحفظ على القرص
    tax       REAL GENERATED ALWAYS AS (qty * unit * 0.08) STORED
);

INSERT INTO orders (qty, unit) VALUES (3, 19.99);
SELECT * FROM orders;

النموذج الذهني للموضوع:

• VIRTUAL — لا يأخذ أي مساحة على القرص، لكنه يستهلك المعالج في كل قراءة. سهل الإضافة وسهل التعديل لاحقًا.
• STORED — يستهلك مساحة تخزين، لكنه لا يكلّفك شيئًا إضافيًا عند القراءة. يستحق العناء عندما يكون التعبير مكلفًا حسابيًا، أو عندما يُقرأ العمود أضعاف مرات الكتابة عليه.

إن لم تكتب الكلمة المفتاحية، فالافتراضي هو VIRTUAL. وهذا هو الخيار الصحيح في معظم الحالات.

لماذا نستخدمها أصلًا؟ فهرسة القيم المُشتقّة

الميزة الأقوى في الأعمدة المُولَّدة في SQLite هي إمكانية إنشاء فهرس عليها. هذا يمنحك بحثًا سريعًا على قيم مُشتقّة دون الحاجة إلى إعادة كتابة كل استعلاماتك.

لنفترض أنك تريد البحث عن البريد الإلكتروني بصرف النظر عن حالة الأحرف:

CREATE TABLE users (
    id           INTEGER PRIMARY KEY,
    email        TEXT NOT NULL,
    email_lower  TEXT GENERATED ALWAYS AS (lower(email)) VIRTUAL
);

CREATE INDEX users_email_lower ON users(email_lower);

INSERT INTO users (email) VALUES ('Ada@Example.com'), ('boris@example.com');

SELECT id, email FROM users WHERE email_lower = 'ada@example.com';

يُغطي الفهرس النسخة المكتوبة بأحرف صغيرة. أيّ استعلام يُرشِّح على email_lower يستفيد من الفهرس مباشرةً. صحيحٌ أنّ SQLite يدعم فهارس التعابير (CREATE INDEX ... ON users(lower(email)))، لكنّ العمود المُولَّد يجعل القيمة المُشتقّة ظاهرةً كعمودٍ حقيقي يمكنك استخدامه في SELECT، والإشارة إليه داخل العروض (Views)، وإعادة استخدامه من شيفرة التطبيق.

استخراج القيم من JSON

تتألّق الأعمدة المُولَّدة في SQLite عند التعامل مع JSON. يمنحك دعم JSON المدمج في SQLite المُعامل ->> لاستخراج قيمة مفردة؛ ضَع هذا التعبير داخل عمودٍ مُولَّد، وستحصل على حقلٍ مُحدَّد النوع وقابلٍ للفهرسة فوق كتلةٍ مرنة من البيانات.

CREATE TABLE events (
    id       INTEGER PRIMARY KEY,
    payload  TEXT NOT NULL,
    user_id  INTEGER GENERATED ALWAYS AS (payload ->> '$.user_id') VIRTUAL,
    kind     TEXT    GENERATED ALWAYS AS (payload ->> '$.kind') VIRTUAL
);

CREATE INDEX events_user_id ON events(user_id);

INSERT INTO events (payload) VALUES
    ('{"user_id": 1, "kind": "login"}'),
    ('{"user_id": 2, "kind": "purchase"}'),
    ('{"user_id": 1, "kind": "logout"}');

SELECT id, kind FROM events WHERE user_id = 1;

user_id و kind يبدوان كأعمدة عادية بالنسبة لاستعلاماتك، لكن البيانات الفعلية مخزَّنة داخل payload. غيّر محتوى الـ JSON، وستتحدّث قيم الأعمدة تلقائيًا. ووجود فهرس على user_id يجعل عمليات البحث سريعة جدًا.

القواعد والقيود

هناك بعض الأمور التي تفرضها SQLite، ومن الأفضل أن تعرفها قبل أن تصطدم بها:

• يجب أن يكون التعبير حتميًا (deterministic). أي أن دوال مثل random() و datetime('now') وغيرها من الدوال غير الحتمية ممنوعة. القيمة يجب أن تكون قابلة لإعادة الحساب من بيانات نفس الصف.
• التعبير لا يمكنه الإشارة إلا إلى أعمدة من نفس الصف. ممنوع استخدام الاستعلامات الفرعية أو دوال التجميع أو الإشارة إلى جداول أخرى.
• لا يمكنك تنفيذ INSERT أو UPDATE على عمود مُولَّد بشكل مباشر. فمثلًا INSERT INTO products (total) VALUES (5) سيُرجع خطأ.
• الأعمدة من نوع STORED لا يمكن إضافتها عبر ALTER TABLE ... ADD COLUMN. فقط أعمدة VIRTUAL هي التي يمكن إضافتها لاحقًا بعد إنشاء الجدول.
• تستطيع الأعمدة المُولَّدة أن تحمل قيود NOT NULL و CHECK و UNIQUE، بل وحتى FOREIGN KEY. فهي تتصرّف مثل أي عمود آخر فيما يخصّ هذه القيود.

ولنرَ مثالًا سريعًا يوضّح قاعدة منع الكتابة المباشرة:

sqlite> INSERT INTO products (price, tax, total) VALUES (10, 1, 999);
Runtime error: cannot INSERT into generated column "total"

الحل ببساطة هو حذف العمود المُولَّد من قائمة INSERT وترك SQLite يحسبه تلقائيًا.

الفرق بين VIRTUAL و STORED في SQLite

عادةً يعتمد الاختيار بين النوعين على نسبة القراءة إلى الكتابة وعلى تكلفة التعبير المحسوب:

CREATE TABLE measurements (
    id          INTEGER PRIMARY KEY,
    celsius     REAL NOT NULL,
    -- عمليات حسابية بسيطة، لا بأس بإعادة حسابها عند كل قراءة.
    fahrenheit  REAL GENERATED ALWAYS AS (celsius * 9.0 / 5.0 + 32) VIRTUAL,
    -- تعبير أثقل، يُستعلَم عنه كثيرًا ويُكتب نادرًا ← خزّنه.
    bucket      TEXT GENERATED ALWAYS AS (
        CASE
            WHEN celsius < 0  THEN 'freezing'
            WHEN celsius < 15 THEN 'cool'
            WHEN celsius < 25 THEN 'mild'
            ELSE 'hot'
        END
    ) STORED
);

INSERT INTO measurements (celsius) VALUES (-3), (10), (22), (31);
SELECT celsius, fahrenheit, bucket FROM measurements;

قواعد عامة مفيدة:

• خلِّ VIRTUAL هو الخيار الافتراضي. ما يكلّفك شي عند الكتابة، ويفي بالغرض في معظم الحالات.
• انتقل إلى STORED لما تحتاج تعمل فهرسة على العمود في جدول كثير الكتابة (الفهرس أصلاً يحتاج القيمة مخزّنة)، أو لما يكون التعبير مُكلِفاً فعلاً.
• لا تضيّع وقتك في الحيرة. النوع جزء من تعريف الـ schema، لكن تقدر تحذف العمود وتعيد إنشاءه لو غيّرت رأيك — على الأقل مع VIRTUAL.

الأعمدة المُولَّدة مقابل الـ Views

في تداخل بين الاثنين: كلاهما يعرض قيماً محسوبة دون تخزينها (أحياناً). والتفريق عادةً يكون كذا:

• العمود المُولَّد يخصّ صفّاً واحداً في جدول واحد. استعمله للاشتقاقات على مستوى الصف — تنسيق بريد إلكتروني، استخراج حقل من JSON، حساب مجموع.
• الـ view عبارة عن استعلام محفوظ. استعمله لما تحتاج عمليات تشمل joins أو تجميع (aggregation) أو فلترة عبر عدة صفوف.

ولا مانع من الجمع بينهما. تقدر تكتب view يعمل SELECT على جدول فيه أعمدة مُولَّدة ويضمّ معه بيانات إضافية بـ join. الأعمدة المُولَّدة تشتغل في طبقة التخزين، أما الـ views فتشتغل في طبقة الاستعلام.

التالي: ATTACH DATABASE

الأعمدة المُولَّدة تتيح للجدول أن يحسب قيمه بنفسه. الصفحة الجاية تأخذنا في الاتجاه المعاكس: ربط أكثر من قاعدة بيانات SQLite في نفس الوقت عن طريق ATTACH DATABASE، بحيث يمتدّ الاستعلام الواحد عبر عدة ملفات.