التصفية والترتيب بهدف

تكتب هدى صالح، نائبة الرئيس للتسويق: «هل يمكنك أن تستخرج الطلبات التي استخدمت SPRING15 أو WELCOME10 على قنواتنا الخاصة، الويب أو التطبيق؟ أريد أن أعرف هل يجذب عرض الترحيب الناس إلى التطبيق». في جملتها «أو» مرتين و«و» مرة واحدة. هذا هو شكل الطلبات الذي ينتج أرقامًا خاطئة دون أي إنذار، لذا يستحق WHERE أن تضبطه تمامًا.

AND قبل OR

هذه هي المسودة الأولى التي يكتبها معظم الناس، بترجمة كلماتها من اليسار إلى اليمين:

SELECT COUNT(*) AS orders
FROM orders
WHERE channel = 'web' OR channel = 'mobile_app'
  AND coupon_code IN ('SPRING15', 'WELCOME10');

1,191 طلبًا. هذا أكثر من نصف كل الطلبات خلال سنتين، من أجل كوبونين محدودين. الرقم نفسه هو جرس الإنذار: AND يرتبط أقوى من OR، فقرأ SQL الشرط هكذا: «كل طلبات الويب، إضافةً إلى طلبات التطبيق التي استخدمت كوبونًا». كل طلب ويب موجود في النتيجة، بكوبون أو بدونه.

الأقواس تقول ما قصدته هدى:

SELECT COUNT(*) AS orders
FROM orders
WHERE (channel = 'web' OR channel = 'mobile_app')
  AND coupon_code IN ('SPRING15', 'WELCOME10');

110 طلبات. والأفضل أن يستخدم اختبار القناة IN أيضًا، فيختفي OR تمامًا: channel IN ('web', 'mobile_app'). يفحص IN عمودًا واحدًا مقابل قائمة، والقائمة لا يمكن أن تُجمَّع بشكل خاطئ.

بقية أدوات التصفية

بضعة معاملات تغطي في الغالب كل شرط ستكتبه:

لمقارنة النصوص في 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
FROM products
WHERE name LIKE '%mat%'
  AND unit_price BETWEEN 20 AND 80;

قول «لا» بشكل صحيح

النفي هو المكان الذي يتعثّر فيه حتى الحذِرون. لنفترض أن هدى تريد الآن الطلبات التي ليست ملغاة ولا مرتجعة. يمكنك كتابتها بطريقتين متكافئتين:

SELECT
  (SELECT COUNT(*) FROM orders
   WHERE NOT (status = 'cancelled' OR status = 'returned')) AS not_either,
  (SELECT COUNT(*) FROM orders
   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؛ فإن حدث ذلك فالمنطق خاطئ. فحص كهذا يستغرق عشر ثوانٍ ويلتقط معظم الأخطاء المنطقية قبل أن يراها أحد غيرك.

التواريخ في Cartwheel نصوص بصيغة ISO (2025-11-28 19:55:30)، وترتيبها الأبجدي يطابق ترتيبها الزمني. لذا يعمل order_date >= '2025-11-01' كشرط على التاريخ. تتناول الدروس القادمة الفخاخ، بدءًا بما يحدث عند نهاية اليوم.

ترتيب يمكنك الاعتماد عليه

يقبل ORDER BY عدة مفاتيح، لكلٍّ منها اتجاهه. المفتاح الثاني لا يؤثّر إلا بين الصفوف المتساوية في الأول:

SELECT order_id, customer_id, order_date, coupon_code
FROM orders
WHERE channel = 'marketplace'
  AND coupon_code IS NOT NULL
ORDER BY order_date DESC, order_id
LIMIT 5;

لماذا نضيف order_id والتواريخ نادرًا ما تتساوى؟ لأن «نادرًا» ليست «أبدًا». حين يتساوى صفّان في كل مفاتيح الترتيب، لا يَعِد SQL بأي ترتيب بينهما، وقد يختلف من تشغيل إلى آخر. إنهاء الـ ORDER BY بعمود فريد، وهو عادةً المفتاح الأساسي، يجعل الترتيب حتميًا تمامًا.

وهذا أهم ما يكون في تقسيم الصفحات. LIMIT 20 OFFSET 40 يعني «تخطَّ 40 صفًا وأعِد الـ 20 التالية»، أي الصفحة الثالثة من 20. إذا لم يكن الترتيب حتميًا، فقد يظهر صف في الصفحة الثانية ثم مرة أخرى في الثالثة.

أُجيب عن سؤال هدى عن الكوبونات: 110 طلبات. وسؤالها التالي في التمرين أدناه. بعد ذلك تأتي القيمة التي تُربك كل هذه المعاملات بطرق مفاجئة: NULL.