تكتب هدى صالح، نائبة الرئيس للتسويق: «هل يمكنك أن تستخرج الطلبات التي استخدمت SPRING15 أو WELCOME10 على قنواتنا الخاصة، الويب أو التطبيق؟ أريد أن أعرف هل يجذب عرض الترحيب الناس إلى التطبيق». في جملتها «أو» مرتين و«و» مرة واحدة. هذا هو شكل الطلبات الذي ينتج أرقامًا خاطئة دون أي إنذار، لذا يستحق WHERE أن تضبطه تمامًا.
هذه هي المسودة الأولى التي يكتبها معظم الناس، بترجمة كلماتها من اليسار إلى اليمين:
\nSELECT COUNT(*) AS orders\nFROM orders\nWHERE channel = 'web' OR channel = 'mobile_app'\n AND coupon_code IN ('SPRING15', 'WELCOME10');1,191 طلبًا. هذا أكثر من نصف كل الطلبات خلال سنتين، من أجل كوبونين محدودين. الرقم نفسه هو جرس الإنذار: AND يرتبط أقوى من OR، فقرأ SQL الشرط هكذا: «كل طلبات الويب، إضافةً إلى طلبات التطبيق التي استخدمت كوبونًا». كل طلب ويب موجود في النتيجة، بكوبون أو بدونه.
الأقواس تقول ما قصدته هدى:
\nSELECT COUNT(*) AS orders\nFROM orders\nWHERE (channel = 'web' OR channel = 'mobile_app')\n AND coupon_code IN ('SPRING15', 'WELCOME10');110 طلبات. والأفضل أن يستخدم اختبار القناة IN أيضًا، فيختفي OR تمامًا: channel IN ('web', 'mobile_app'). يفحص IN عمودًا واحدًا مقابل قائمة، والقائمة لا يمكن أن تُجمَّع بشكل خاطئ.
بضعة معاملات تغطي في الغالب كل شرط ستكتبه:
\n| المعامل | \nمثال | \nملاحظة | \n
|---|---|---|
IN (...) | \nstatus IN ('cancelled', 'returned') | \nNOT IN للاستبعاد؛ احذر من NULL (الدرس التالي) | \n
BETWEEN a AND b | \nshipping_fee BETWEEN 5 AND 10 | \nيشمل الطرفين | \n
LIKE | \nname LIKE '%mat%' | \n% أي سلسلة من الأحرف، و_ حرف واحد بالضبط | \n
<> / != | \nstatus <> 'cancelled' | \nكلاهما يعني «لا يساوي» | \n
لمقارنة النصوص في SQLite خصوصية. = حسّاس لحالة الأحرف، فـ 'a' = 'A' قيمته false، بينما يتجاهل LIKE حالة الأحرف الإنجليزية، فـ 'a' LIKE 'A' قيمته true. لهذا يجد name LIKE '%mat%' كلًّا من “Desk Mat XL” و"Cork Yoga Mat". أما LIKE في PostgreSQL فحسّاس لحالة الأحرف، وهو فرق ستقابله مجددًا في درس اللهجات.
SELECT product_id, name, unit_price\nFROM products\nWHERE name LIKE '%mat%'\n AND unit_price BETWEEN 20 AND 80;النفي هو المكان الذي يتعثّر فيه حتى الحذِرون. لنفترض أن هدى تريد الآن الطلبات التي ليست ملغاة ولا مرتجعة. يمكنك كتابتها بطريقتين متكافئتين:
\nSELECT\n (SELECT COUNT(*) FROM orders\n WHERE NOT (status = 'cancelled' OR status = 'returned')) AS not_either,\n (SELECT COUNT(*) FROM orders\n WHERE status <> 'cancelled' AND status <> 'returned') AS both_not;كلاهما يعيد 1,864. القاعدة وراء ذلك هي قانون De Morgan: إدخال NOT إلى داخل القوسين يقلب كل OR إلى AND (وكل AND إلى OR). الخطأ الشائع أن تقلب المقارنات وتنسى قلب أداة الربط: status <> 'cancelled' OR status <> 'returned' قيمته TRUE لكل صف، لأن أي حالة تختلف عن واحدة من الاثنتين على الأقل. حين تكتب شرطًا منفيًا، فإن NOT IN ('cancelled', 'returned') هو أوضح صيغة على الإطلاق.
وهناك عادة أخرى تؤتي ثمارها هنا. قبل أن تثق بشرط فيه عدة أجزاء، عُدّ الصفوف لكل جزء وحده. لشرط هدى ثلاثة أجزاء: الويب أو التطبيق يُبقي 1,848 صفًا، والكوبونان يُبقيان 127، و«ليست ملغاة ولا مرتجعة» يُبقي 1,864. ولا يمكن لربطها بـ AND أن يُبقي أكثر من أصغرها، أي 127؛ فإن حدث ذلك فالمنطق خاطئ. فحص كهذا يستغرق عشر ثوانٍ ويلتقط معظم الأخطاء المنطقية قبل أن يراها أحد غيرك.
\nالتواريخ في Cartwheel نصوص بصيغة ISO (2025-11-28 19:55:30)، وترتيبها الأبجدي يطابق ترتيبها الزمني. لذا يعمل order_date >= '2025-11-01' كشرط على التاريخ. تتناول الدروس القادمة الفخاخ، بدءًا بما يحدث عند نهاية اليوم.
يقبل ORDER BY عدة مفاتيح، لكلٍّ منها اتجاهه. المفتاح الثاني لا يؤثّر إلا بين الصفوف المتساوية في الأول:
SELECT order_id, customer_id, order_date, coupon_code\nFROM orders\nWHERE channel = 'marketplace'\n AND coupon_code IS NOT NULL\nORDER BY order_date DESC, order_id\nLIMIT 5;لماذا نضيف order_id والتواريخ نادرًا ما تتساوى؟ لأن «نادرًا» ليست «أبدًا». حين يتساوى صفّان في كل مفاتيح الترتيب، لا يَعِد SQL بأي ترتيب بينهما، وقد يختلف من تشغيل إلى آخر. إنهاء الـ ORDER BY بعمود فريد، وهو عادةً المفتاح الأساسي، يجعل الترتيب حتميًا تمامًا.
وهذا أهم ما يكون في تقسيم الصفحات. LIMIT 20 OFFSET 40 يعني «تخطَّ 40 صفًا وأعِد الـ 20 التالية»، أي الصفحة الثالثة من 20. إذا لم يكن الترتيب حتميًا، فقد يظهر صف في الصفحة الثانية ثم مرة أخرى في الثالثة.
أُجيب عن سؤال هدى عن الكوبونات: 110 طلبات. وسؤالها التالي في التمرين أدناه. بعد ذلك تأتي القيمة التي تُربك كل هذه المعاملات بطرق مفاجئة: NULL.
ما الصفوف التي يُبقيها هذا الشرط؟
\nWHERE status = 'delivered' OR status = 'shipped' AND channel = 'web'status = 'delivered' OR (status = 'shipped' AND channel = 'web')."}],"answer":3},{"q":"تحتاج إلى طلبات الويب من العميل 42، وقد تكون قيمة القناة مخزّنة بالشكل ‘Web’ أو ‘web’. أي اختبار يطابق الاثنين؟
","options":[{"text":"channel = 'web'","why":"في SQLite يقارن = النص مع مراعاة حالة الأحرف، فلن تطابق ‘Web’."},{"text":"channel IN ('web')","why":"IN يستخدم مقارنة المساواة نفسها التي يستخدمها =، فهو حسّاس لحالة الأحرف أيضًا."},{"text":"channel LIKE 'web'","why":"صحيح. LIKE في SQLite لا يميّز حالة الأحرف الإنجليزية افتراضيًا، فيطابق الكتابتين. وLOWER(channel) = 'web' يعمل أيضًا."}],"answer":2},{"q":"لوحة معلومات تعرض الطلبات 20 في كل صفحة باستخدام ORDER BY order_date LIMIT 20 OFFSET 40. يشتكي المستخدمون من ظهور طلب في صفحتين. ما الإصلاح الأرجح؟
order_id كمفتاح ترتيب ثانٍ حتى تأتي الصفوف ذات التواريخ المتساوية بالترتيب نفسه دائمًا.","why":"صحيح. حين تتساوى قيم order_date قد تعيد قاعدة البيانات الصفوف المتساوية بترتيب مختلف في كل query، فيقع صف واحد في صفحتين."},{"text":"استبدل OFFSET بـ LIMIT أكبر حتى تقلّ الصفحات المطلوبة.","why":"هذا يخفي العَرَض في الجداول الصغيرة، لكنه لا يجعل الترتيب حتميًا."},{"text":"رتّب بـ DESC بدل ASC.","why":"الاتجاه لا يهم؛ الصفوف المتساوية غامضة الترتيب في الاتجاه التنازلي أيضًا."}],"answer":0},{"q":"BETWEEN 10 AND 20 على العمود shipping_fee: أي قيمة لا تدخل في النتيجة؟
x BETWEEN a AND b يعني x >= a AND x <= b."},{"text":"20","why":"BETWEEN يشمل حدّه الأعلى أيضًا، وهذا ما يوقع الناس في المشاكل مع التواريخ لاحقًا."},{"text":"15.5","why":"أي قيمة بين الحدّين تدخل، والكسور كذلك."},{"text":"20.01","why":"صحيح. إنها أكبر من الحدّ الأعلى. أما الحدّان نفساهما فيدخلان."}],"answer":3}],"exercise":{"kind":"sql","starter":"-- BLACKFRIDAY25 used outside November 2025, web or app, not cancelled\nSELECT order_id, order_date, channel\nFROM orders\nWHERE coupon_code = 'BLACKFRIDAY25'\n AND channel = 'web' OR channel = 'mobile_app'\n AND status <> 'cancelled'\n AND order_date >= '2025-01-01'\n AND order_date < '2025-11-01' OR order_date >= '2025-12-01'\nORDER BY order_date;","solution":"SELECT order_id, order_date, channel\nFROM orders\nWHERE coupon_code = 'BLACKFRIDAY25'\n AND channel IN ('web', 'mobile_app')\n AND status <> 'cancelled'\n AND order_date >= '2025-01-01'\n AND (order_date < '2025-11-01' OR order_date >= '2025-12-01')\nORDER BY order_date, order_id;","orderMatters":true,"title":"هل يتسرّب BLACKFRIDAY25؟","prompt":"سؤال هدى التالي: «كان BLACKFRIDAY25 مخصّصًا لشهر نوفمبر فقط. أرني كل طلب في 2025 استخدمه خارج نوفمبر، على الويب أو التطبيق، ولم يُلغَ».
\nأعِد order_id وorder_date وchannel، مرتّبة حسب order_date (الأقدم أولًا). الترتيب مهم.
الكود المبدئي يعمل، لكنه يعيد مئات الصفوف. أصلح منطقه.
\n","hints":["عُدّ مرات OR في الكود المبدئي. كل واحدة منها تقسم عبارة WHERE كلها إلى قسمين لأن AND يرتبط أقوى.","استبدل OR الخاص بالقناة بـchannel IN ('web', 'mobile_app').","شرط التاريخ يحتاج إلى أقواس: AND (order_date < '2025-11-01' OR order_date >= '2025-12-01')، بعد السطر الذي يُبقي 2025 فقط."],"explanation":"بدون أقواس، يقسم كل OR الشرط إلى بدائل منفصلة، فأبقى الكود المبدئي كل طلبات التطبيق التي طابقت الشروط اللاحقة وكل الطلبات من ديسمبر فصاعدًا، بكوبون أو بدونه. استخدام IN للقناة يزيل OR واحدًا، ووضع بدائل التاريخ بين قوسين يُبقي الآخر محصورًا في مكانه. النتيجة 22 طلبًا، معظمها على الويب: أمر يستحق أن تنبّه إليه هدى، لأن الكوبون ما زال يعمل طوال السنة بوضوح.