قيود CHECK في SQLite: التحقق من البيانات على مستوى الجدول

قيد CHECK في SQLite: قاعدة يجب أن كل صف يحققها

قيد CHECK هو ببساطة تعبير منطقي (boolean) بترفقه بالجدول، وSQLite بيتحقق منه مع كل عملية INSERT أو UPDATE. لو نتيجة التعبير كانت false، العملية بتفشل وما بتعدّيش. يعني باختصار، ده أسلوب بتدمج بيه قواعد منطق العمل جوّه السكيمة نفسها — زي "السعر ما يبقاش بالسالب"، أو "الحالة يجب أن تكون واحدة من ثلاث قيم محددة".

CREATE TABLE products (
    id    INTEGER PRIMARY KEY,
    name  TEXT NOT NULL,
    price REAL NOT NULL CHECK (price >= 0)
);

INSERT INTO products (name, price) VALUES ('دفتر ملاحظات', 4.50);
INSERT INTO products (name, price) VALUES ('عينة مجانية', 0);
INSERT INTO products (name, price) VALUES ('خطأ', -1);

SELECT * FROM products;

يدخل الصفّان الأوّلان بدون مشاكل، أمّا الصفّ الثالث فيُرفض ويظهر الخطأ CHECK constraint failed — ولا يصل إلى الجدول إطلاقًا. القيد يفرض القاعدة على كلّ من يكتب في الجدول، سواء كان تطبيقك، أو سكربت ترحيل (migration)، أو حتى شخصًا يعبث بالأوامر من الـ CLI.

قيد CHECK على مستوى العمود مقابل مستوى الجدول

يمكنك كتابة قيد CHECK في موضعين: بعد تعريف العمود مباشرةً (على مستوى العمود)، أو بعد تعريف كلّ الأعمدة (على مستوى الجدول). السلوك واحد في الحالتين، والفرق فقط في أيّهما يقرأ بشكل أوضح.

-- على مستوى العمود: قاعدة تخص عمودًا واحدًا.
CREATE TABLE accounts (
    id      INTEGER PRIMARY KEY,
    balance REAL CHECK (balance >= 0)
);

-- على مستوى الجدول: قاعدة تشمل عدة أعمدة.
CREATE TABLE bookings (
    id         INTEGER PRIMARY KEY,
    start_date TEXT NOT NULL,
    end_date   TEXT NOT NULL,
    CHECK (start_date <= end_date)
);

INSERT INTO bookings (start_date, end_date) VALUES ('2026-01-10', '2026-01-15');
INSERT INTO bookings (start_date, end_date) VALUES ('2026-02-01', '2026-01-31');

الحجز الأول ينجح، أما الثاني فيفشل لأن تاريخ النهاية يسبق تاريخ البداية. القواعد التي تخص عمودًا واحدًا تكون أوضح حين تُكتب على مستوى العمود، بينما أي قاعدة تقارن بين عمودين أو أكثر فالأفضل كتابتها على مستوى الجدول.

حصر القيم ضمن قائمة محددة

من أكثر استخدامات قيود CHECK في SQLite شيوعًا هو إجبار العمود على قبول قيمة من مجموعة ثابتة فقط. بما أن SQLite لا يدعم نوع enum بشكل أصلي، فإن الصيغة المعتادة لذلك هي CHECK ... IN (...):

CREATE TABLE tickets (
    id     INTEGER PRIMARY KEY,
    title  TEXT NOT NULL,
    status TEXT NOT NULL CHECK (status IN ('open', 'in_progress', 'closed'))
);

INSERT INTO tickets (title, status) VALUES ('تسجيل الدخول معطل', 'open');
INSERT INTO tickets (title, status) VALUES ('خطأ إملائي في التذييل', 'closed');
INSERT INTO tickets (title, status) VALUES ('غامض', 'pending');

الصف الثالث يفشل لأن القيمة 'pending' ليست ضمن القائمة المسموح بها. ولو احتجت لاحقًا إضافة حالة جديدة، فسيتعيّن عليك إعادة بناء الجدول (سنتطرق لذلك بعد قليل)، لذا فكّر مليًّا قبل أن تُقفل القائمة. لكن مع المفردات الثابتة فعلًا، كأسماء الأدوار أو حالات الطلبات، فهذا القيد هو ما تحتاجه بالضبط.

تسمية قيود CHECK في SQLite

افتراضيًا يكون القيد بلا اسم. ورسالة الخطأ تكتفي بقول "CHECK constraint failed" مع التعبير، وهذا مقبول حين يوجد قيد CHECK واحد على الجدول، لكنه مربك حين تكون لديك خمسة قيود. أضف اسمًا للقيد عبر CONSTRAINT:

CREATE TABLE employees (
    id       INTEGER PRIMARY KEY,
    name     TEXT NOT NULL,
    salary   REAL NOT NULL,
    bonus    REAL NOT NULL DEFAULT 0,
    CONSTRAINT salary_positive CHECK (salary > 0),
    CONSTRAINT bonus_not_negative CHECK (bonus >= 0),
    CONSTRAINT bonus_not_huge CHECK (bonus <= salary)
);

INSERT INTO employees (name, salary, bonus) VALUES ('Ada', 60000, 70000);

الآن أصبحت رسالة الخطأ تتضمن اسم القيد، فتعرف فورًا أيّ قاعدة جرى انتهاكها. صحيح أن التسمية تكلّفك بضعة حروف إضافية، لكنها تردّ لك الجميل أول مرة ينكسر فيها شيء على بيئة الإنتاج.

قيود CHECK مع قيم NULL: المفاجأة غير المتوقعة

قيد CHECK يُعتبر ناجحًا عندما يكون التعبير صحيحًا (true) أو يساوي NULL، ولا يفشل إلا حين تكون النتيجة false صراحةً. يبدو هذا غريبًا للوهلة الأولى، لكن تذكّر أن أي مقارنة مع NULL تنتج عنها قيمة NULL، لا true ولا false.

CREATE TABLE people (
    id  INTEGER PRIMARY KEY,
    age INTEGER CHECK (age >= 0)
);

INSERT INTO people (age) VALUES (25);
INSERT INTO people (age) VALUES (NULL);
INSERT INTO people (age) VALUES (-5);

SELECT * FROM people;

الصف الذي يحمل قيمة NULL يُضاف بدون أي مشكلة — لأن نتيجة NULL >= 0 هي NULL وليست false، وبالتالي قيد CHECK لا يفشل. إذا كنت تريد فعلاً منع الأرقام السالبة والقيم الفارغة في آنٍ واحد، اجمع بين NOT NULL وقيد CHECK كالتالي:

CREATE TABLE people (
    id  INTEGER PRIMARY KEY,
    age INTEGER NOT NULL CHECK (age >= 0)
);

INSERT INTO people (age) VALUES (NULL);

الآن عملية الإدراج تفشل عند قيد NOT NULL قبل أن يصل التنفيذ إلى CHECK أصلاً. القيدان يكمّلان بعضهما: NOT NULL يمنع غياب القيمة، وCHECK يضبط شكلها.

دوال مدمجة مفيدة داخل قيد CHECK

يمكن للتعبير داخل CHECK أن يستخدم معظم الدوال المدمجة في SQLite. وهذه بعض الدوال التي تتكرر كثيراً في الاستخدام العملي:

CREATE TABLE users (
    id       INTEGER PRIMARY KEY,
    email    TEXT NOT NULL CHECK (email LIKE '%_@_%.__%'),
    username TEXT NOT NULL CHECK (length(username) BETWEEN 3 AND 20),
    country  TEXT NOT NULL CHECK (country = upper(country))
);

INSERT INTO users (email, username, country) VALUES ('ada@example.com', 'ada', 'US');
INSERT INTO users (email, username, country) VALUES ('not-an-email', 'ada2', 'US');
INSERT INTO users (email, username, country) VALUES ('boris@x.io', 'b', 'US');
INSERT INTO users (email, username, country) VALUES ('cara@x.io', 'cara', 'us');

ثلاث حالات فشل: بريد إلكتروني بصيغة غير صحيحة، واسم مستخدم أقصر من اللازم، ورمز دولة بأحرف صغيرة. عامل LIKE يكفي للأنماط البسيطة، ويمكنك أيضاً استخدام length() وupper() وlower() والعمليات الحسابية بحرّية. فقط احرص على أن يبقى التعبير حتمياً (deterministic)؛ فاستخدام شيء مثل random() أو current_timestamp داخل CHECK ينتج قاعدة قد تتغير نتيجتها بين صفّ وآخر، وهذا نادراً ما يكون المطلوب.

الفرق بين CHECK و trigger في SQLite

كلاهما قادر على رفض البيانات السيئة، وكثيراً ما يحتار المبتدئ في أيّهما يستخدم. القاعدة العامة:

• استخدم CHECK عندما تعتمد القاعدة على الصف الذي يُكتب فقط. مثل: "مقارنة عمود بعمود آخر"، أو "قيمة ضمن نطاق معين"، أو "نص يطابق نمطاً محدداً".
• استخدم trigger (وتحديداً BEFORE INSERT/UPDATE مع استدعاء RAISE) عندما تعتمد القاعدة على صفوف أخرى أو جداول أخرى، أو تحتاج إلى منطق أعقد من مجرد تعبير منطقي واحد.

قيد CHECK أسرع وأبسط وواضح داخل التعريف نفسه؛ فأي شخص يقرأ CREATE TABLE يرى القاعدة مباشرة. لا تلجأ إلى trigger إلا حين يعجز CHECK عن التعبير عمّا تريده.

لا يمكن حذف قيد CHECK باستخدام ALTER

هذه هي النقطة المزعجة الوحيدة. لا يدعم SQLite الأمر ALTER TABLE ... DROP CONSTRAINT، لذا لإزالة قيد CHECK أو تعديله عليك إعادة بناء الجدول:

BEGIN;

CREATE TABLE products_new (
    id    INTEGER PRIMARY KEY,
    name  TEXT NOT NULL,
    price REAL NOT NULL CHECK (price >= 0 AND price <= 1000000)
);

INSERT INTO products_new SELECT * FROM products;
DROP TABLE products;
ALTER TABLE products_new RENAME TO products;

COMMIT;

غلِّف العملية كلها داخل معاملة (transaction) حتى لو فشل شيء في المنتصف، تبقى قاعدة البيانات سليمة كما هي. وإذا كانت هناك جداول أخرى فيها مفاتيح أجنبية تشير إلى الجدول الذي تعيد بناءه، فالقصة تطول قليلاً: عطِّل foreign_keys، أعد البناء، فعِّلها من جديد، ثم تحقق من سلامة العلاقات. سنتناول هذا الموضوع لاحقاً في درس الـ migrations ضمن المنهج.

ما التالي؟ قيود UNIQUE

قيد CHECK يتحقق من شكل القيم داخل الصف الواحد، أما القيد التالي UNIQUE فيتحقق من العلاقة بين الصفوف بعضها ببعض، إذ يضمن ألا يتشارك صفّان في نفس القيمة ضمن عمود معيّن أو مجموعة أعمدة. هذا ما سنبدأ به في الدرس القادم.