اختبار جاهزية الإنتاج

اختبار جاهزية الإنتاج — Production Readiness Quiz

وصلت إلى نهاية مسار SQL. الفكرة التي يجب أن تبقى معك: قاعدة البيانات ليست مكان تخزين فقط، بل حارس للمعنى. القيود تمنع القيم الخاطئة. المعاملات تمنع نصف التغيير. الفهارس تساعد القراءة عندما تقاس بعناية. والاستعلامات الجيدة تجعل قرارات العمل واضحة.

قبل أي تغيير إنتاجي، اسأل: هل لدي نسخة احتياطية؟ هل أعرف rollback؟ هل الاستعلام يستخدم parameters؟ هل القيود تحمي البيانات؟ هل mutation محدود بـWHERE واضح؟ هل الأداء مقاس؟ هذه الأسئلة ليست تعقيداً؛ هي إتقان.

مراجعة نهائية — Capstone

هذا المثال يجمع المهارات كلها: قيود، فهرس، معاملة متعددة الجمل، EXPLAIN QUERY PLAN، وفحص السلامة.

query.sql

PRAGMA foreign_keys = ON;

-- 1. إنشاء جدول products بقيود صحيحة
CREATE TABLE products (
  id INTEGER PRIMARY KEY,
  name TEXT NOT NULL,
  price_halalas INTEGER NOT NULL CHECK (price_halalas > 0),
  stock INTEGER NOT NULL CHECK (stock >= 0)
);

-- 2. إنشاء فهرس على name للبحث السريع
CREATE INDEX idx_products_name ON products(name);

-- 3. إدراج 3 منتجات
INSERT INTO products VALUES
  (1, 'قلم', 500,  100),
  (2, 'دفتر', 1200, 50),
  (3, 'حقيبة', 25000, 10);

-- 4. إنشاء جدول orders
CREATE TABLE orders (
  id INTEGER PRIMARY KEY,
  product_id INTEGER NOT NULL REFERENCES products(id),
  quantity INTEGER NOT NULL CHECK (quantity > 0)
);

-- 5. تسجيل طلب وتخفيض المخزون في معاملة واحدة
BEGIN;
INSERT INTO orders (id, product_id, quantity) VALUES (1, 1, 3);
UPDATE products
  SET stock = stock - 3
  WHERE id = 1 AND stock >= 3;
COMMIT;

-- 6. التحقق من EXPLAIN QUERY PLAN
EXPLAIN QUERY PLAN
SELECT name, stock FROM products WHERE name = 'قلم';

-- 7. فحص سلامة قاعدة البيانات
PRAGMA integrity_check;

Output:

التحدي الأخير

هذا هو الاختبار الذي يجمع المسار كله في عملية إنتاجية واحدة: سجّل طلباً وخفّض المخزون داخل معاملة واحدة، بخصم نسبي (stock - 1) لا بقيمة مكتوبة يدوياً، وبشرط WHERE يمنع الرصيد السالب — ثم اعرض القيمة النهائية. النتيجة الصحيحة 2، لكن الطريقة هي موضوع الاختبار، وليس الرقم.

تحدي — Challenge

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

CREATE TABLE orders (
  id INTEGER PRIMARY KEY,
  product_id INTEGER NOT NULL REFERENCES products(id),
  quantity INTEGER NOT NULL CHECK (quantity > 0)
);

INSERT INTO products VALUES (1, 3);

-- سجّل الطلب وخفّض المخزون داخل معاملة واحدة، ثم اعرض المخزون

مراجعة المفاهيم

الكابستون اختبر التنفيذ. هذه الأسئلة تختبر عقلية الإنتاج نفسها — الأدلة قبل الثقة. أجب قبل أن تنظر إلى الشرح.

سؤال — Question

أنشأت فهرساً على name — لماذا لا يكفي هذا، وما الذي يضيفه EXPLAIN QUERY PLAN؟

يكفي — وجود الفهرس يضمن استخدامه في كل استعلام على العمود لأن المحرك قد يتجاهل الفهرس؛ الخطة تريك القرار الفعلي — SEARCH مع الفهرس أم SCAN كامل الخطة تجعل الاستعلام أسرع عند تشغيلها قبله الخطة تصلّح الفهارس المكسورة تلقائياً

وجود الفهرس لا يعني استخدامه — دالة على العمود أو نوع غير متطابق أو إحصاءات قديمة قد تجعل المحرك يمسح الجدول كاملاً رغم الفهرس. EXPLAIN QUERY PLAN يريك القرار الفعلي: SEARCH ... USING INDEX يعني الفهرس يعمل، وSCAN يعني مسحاً كاملاً. قِس، لا تفترض.

سؤال — Question

لماذا نكتب SET stock = stock - 1 بدل حساب القيمة الجديدة في التطبيق وكتابتها مباشرة (SET stock = 2)؟

لأن SQLite لا يقبل القيم الثابتة في SET لأن الطرح داخل SQL أسرع من الطرح في التطبيق لأن القيمة المحسوبة خارجاً تبني على قراءة قد شاخت — الخصم النسبي يحسب على القيمة الحالية داخل المحرك فلا يمحو خصم طلبٍ متزامن لأن القيم الثابتة تتجاوز قيد CHECK

القيمة المحسوبة في التطبيق — «قرأتُ 3 فسأكتب 2» — تعتمد على قراءة قد تكون شاخت قبل وصول الكتابة: طلب آخر خصم في الأثناء فتكتب أنت فوق خصمه وتمحوه. الخصم النسبي stock = stock - 1 يجعل الحساب يحدث داخل المحرك على القيمة الحالية لحظة التنفيذ، وشرط WHERE stock >= 1 يرفض البيع عند النفاد.

سؤال — Question

ما الذي يجعل الاستعلامات المعاملة (parameterized) الدفاع الصحيح ضد SQL Injection؟

فصل نص الاستعلام عن القيم يجعل أي مدخل يصل كقيمة خام لا كمنطق قابل للتنفيذ أنها تشفّر الاستعلام قبل إرساله أنها تمنع المستخدم من كتابة علامات اقتباس أنها تسجّل كل استعلام في ملف مراجعة

الاستعلام المعامل يرسل النص والقيم منفصلين، فتصل القيمة قيمةً مهما احتوت — حتى ' OR '1'='1 تُخزَّن كنص بريء ولا تُنفَّذ كمنطق. دمج المدخلات في نص الاستعلام هو ثغرة الحقن الكلاسيكية، ولا يُغني عنه أي «تنظيف» يدوي للمدخلات.

استرجع الآن الأدوات نفسها من ذاكرتك — هي فحوصات ما قبل أي تغيير إنتاجي.

أكمل الفراغ — Fill in the blank

ما الأمر الذي يكشف هل سيستخدم استعلامك فهرساً أم سيمسح الجدول كاملاً؟

EXPLAIN QUERY PLAN قبل الاستعلام يكشف استراتيجية المحرك — فهرس أم مسح كامل — دون تنفيذ الاستعلام على بياناتك. أول أداة تمسكها عند أي سؤال أداء.

أكمل الفراغ — Fill in the blank

ما الـ PRAGMA الذي يجب تفعيله في كل اتصال SQLite كي تُفرض قيود REFERENCES فعلاً؟

فرض المفاتيح الأجنبية في SQLite معطّل تاريخياً بشكل افتراضي لكل اتصال — PRAGMA foreign_keys = ON; في أول الجلسة هو ما يجعل REFERENCES قيداً حقيقياً لا توثيقاً. لهذا يبدأ به الكابستون أعلاه.

ماذا بعد؟

استخدم SQL يومياً مع بيانات صغيرة حقيقية. ابدأ بتقارير قراءة، ثم تعلم mutations في بيئة آمنة، ثم ارفع المستوى إلى فهارس ومعاملات وmigrations. لا تتعامل مع قاعدة البيانات بخفة؛ هي ذاكرة العمل، ومن يحترمها يكتب تطبيقات أهدأ وأقوى.