يعود مارك من العمليات بالسؤال الذي لم تستطع الإجابة عنه في الدرس الماضي: «ما متوسط وقت الحل لدينا، حسب الأولوية؟». تعرف كيف تحسب ساعات تذكرة واحدة. أما الآن فتحتاج إلى صف واحد لكل أولوية، يلخّص كلٌّ منها عشرات التذاكر. هذا ما يفعله GROUP BY، والفكرة التي تحته، أي مستوى تفصيل النتيجة، هي أنفع مفهوم منفرد في SQL التحليلي.
لكل جدول ولكل نتيجة مستوى تفصيل (grain): الشيء الذي يمثّله الصف الواحد. في support_tickets صف واحد لكل تذكرة. ومارك يريد صفًا واحدًا لكل أولوية. اكتب ذلك أولًا، ثم اجعل الـ query يطابقه:
SELECT\n priority,\n COUNT(*) AS tickets,\n COUNT(closed_at) AS closed,\n ROUND(AVG((julianday(closed_at) - julianday(opened_at)) * 24), 1) AS avg_hours,\n ROUND(MAX((julianday(closed_at) - julianday(opened_at)) * 24), 1) AS max_hours\nFROM support_tickets\nGROUP BY priority\nORDER BY avg_hours;أربعة صفوف، صف لكل أولوية، وهذا يطابق مستوى التفصيل الذي حدّدته. التذاكر العاجلة تُغلق في 6.5 ساعات في المتوسط، والمرتفعة في يوم واحد أو نحوه، والمنخفضة والعادية في أكثر من ثلاثة أيام. لاحظ كيف يتخطّى COUNT(closed_at) وAVG التذاكر المفتوحة بصمت، كما وعدت الدروس السابقة تمامًا. والعمود max_hours مهم أيضًا: قد يبدو المتوسط جيدًا بينما انتظر عميل واحد أسبوعًا كاملًا.
يشرح هذا المخطط معظم أخطاء GROUP BY. يعمل WHERE قبل أن توجد المجموعات، فلا يستطيع أن يختبر COUNT(*)؛ هذه مهمة HAVING. ويعمل ORDER BY بعد SELECT، فيستطيع دائمًا استخدام الاسم المستعار لعمود. يقبل SQLite وPostgreSQL أيضًا الاسم المستعار في GROUP BY من باب التسهيل، ولهذا يعمل GROUP BY month أدناه، لكن الترتيب المنطقي يبقى كما في المخطط.
يريد كريم من المالية أن يعرف أي المنتجات باعت 100 وحدة على الأقل بسعرها الكامل، دون أي خصم. عدد الوحدات لكل منتج قيمة تجميعية، فيذهب الحدّ إلى HAVING. أما «دون خصم» فصفة لكل سطر طلب على حدة، أي أنه شرط على الصفوف ومكانه WHERE:
SELECT\n product_id,\n SUM(quantity) AS units,\n COUNT(DISTINCT order_id) AS orders\nFROM order_items\nWHERE discount = 0\nGROUP BY product_id\nHAVING SUM(quantity) >= 100\nORDER BY units DESC\nLIMIT 5;اقرأه بترتيب المخطط: أسقِط السطور المخفّضة، وجمّع الباقي حسب المنتج، وأبقِ المنتجات التي لها 100 وحدة أو أكثر، ثم احسب ورتّب واقصّ. يعدّ COUNT(DISTINCT order_id) الطلبات لا السطور، لأن كل منتج في بيانات Cartwheel يظهر مرة واحدة على الأكثر في كل طلب، فلا يختلف عدد السطور عن عدد الطلبات إلا حين تعدّ عبر منتجات مختلفة.
تسأل هدى من التسويق عن نسبة طلبات كل شهر التي جاءت عبر تطبيق الجوال. تحتاج إلى عددين لكل شهر: كل الطلبات، وطلبات التطبيق. عبارة FILTER تقصر دالة تجميع واحدة على بعض الصفوف:
SELECT\n strftime('%Y-%m', order_date) AS month,\n COUNT(*) AS orders,\n COUNT(*) FILTER (WHERE channel = 'mobile_app') AS app_orders,\n ROUND(100.0 * COUNT(*) FILTER (WHERE channel = 'mobile_app') / COUNT(*), 1) AS app_pct\nFROM orders\nWHERE order_date >= '2025-07-01'\n AND order_date < '2026-01-01'\nGROUP BY month\nORDER BY month;تتراوح حصة التطبيق بين 28% و40% على وجه التقريب، وحجم نوفمبر يزيد على ثلاثة أضعاف حجم يوليو بفضل Black Friday. هناك تفصيلان مهمّان. استخدام 100.0 بدل 100 يفرض القسمة العشرية؛ فـ SQLite يقسم الأعداد الصحيحة قسمة صحيحة، و47 / 129 تساوي 0. وFILTER جزء من SQL القياسي، ويدعمه SQLite وPostgreSQL. في المحرّكات التي لا تدعمه، اكتب SUM(CASE WHEN channel = 'mobile_app' THEN 1 ELSE 0 END)، وهو العدد نفسه بصيغة أطول.
حين يعمل query مجمَّع، تحقّق منه قبل أن تُبلغ به:
\nلا يستغرق أيٌّ من هذه الفحوص أكثر من دقيقة، ومعًا تلتقط أغلب أخطاء التجميع قبل أن يلتقطها أصحاب الطلب. اجعلها جزءًا من الحلقة التي بدأتها في الدرس الأول، بين «اكتب الـ query» و«أجب». ويصبح الفحص الثالث حيويًا في الدروس القادمة، حين تبدأ بربط الجداول. فالـ JOIN قد يغيّر مستوى التفصيل دون أن يخبرك، والجمع على مستوى تفصيل خاطئ هو بداية الحساب المزدوج.
\n","toc":[{"id":"sec-1","text":"صف واحد لكل ماذا؟","level":2},{"id":"sec-2","text":"WHERE مقابل HAVING","level":2},{"id":"sec-3","text":"عدّ جزء من الصفوف داخل كل مجموعة","level":2},{"id":"sec-4","text":"التحقق من مستوى التفصيل","level":2}],"takeaways":["مستوى التفصيل (grain) في النتيجة هو ما يمثّله الصف الواحد؛ قُله بصوت عالٍ قبل كتابة GROUP BY، وتحقّق منه بعدها.","كل عمود في قائمة SELECT يجب أن يكون إمّا في GROUP BY أو داخل دالة تجميع؛ يسمح SQLite بالأعمدة المجرّدة لكنه يملؤها من صف اعتباطي.","يصفّي WHERE الصفوف قبل التجميع، ويصفّي HAVING المجموعات بعده، لذا تنتمي الشروط على SUM أو COUNT إلى HAVING.","COUNT(*) FILTER (WHERE …) أو SUM(CASE WHEN … THEN 1 ELSE 0 END) يعدّ جزءًا من الصفوف داخل كل مجموعة دون query ثانٍ."],"further":[{"title":"SQLite aggregate functions","url":"https://www.sqlite.org/lang_aggfunc.html"},{"title":"SQLite SELECT processing, including bare columns","url":"https://www.sqlite.org/lang_select.html#resultset"},{"title":"PostgreSQL aggregate expressions and FILTER","url":"https://www.postgresql.org/docs/current/sql-expressions.html#SYNTAX-AGGREGATES"}],"quiz":[{"q":"تحتاج إلى الدول التي يزيد عدد طلباتها في 2025 على 50. أين يذهب كل شرط؟
","options":[{"text":"شرط السنة وCOUNT(*) > 50 كلاهما في WHERE.","why":"يعمل WHERE قبل التجميع، حين لا يكون هناك عدد بعد، فوضع دالة تجميع فيه خطأ."},{"text":"كلاهما في HAVING.","why":"يرفض PostgreSQL وجود order_date غير المجمَّع في HAVING، أما SQLite فيختبر تاريخ صف اعتباطي واحد من كل مجموعة، فتخرج الأعداد خاطئة بصمت. شرط السنة شرط على الصفوف ومكانه WHERE."},{"text":"شرط السنة في HAVING، وCOUNT(*) > 50 في WHERE.","why":"هذا معكوس. WHERE لا يرى دوال التجميع أصلًا."},{"text":"شرط السنة في WHERE، وCOUNT(*) > 50 في HAVING.","why":"صحيح. صفِّ الصفوف أولًا (طلبات 2025 فقط)، ثم صفِّ المجموعات حسب قيمة التجميع."}],"answer":3},{"q":"ما مستوى التفصيل في هذه النتيجة؟
\nSELECT customer_id, strftime('%Y-%m', order_date) AS month, COUNT(*)\nFROM orders\nGROUP BY customer_id, month;في SQLite يعمل SELECT channel, status, COUNT(*) FROM orders GROUP BY channel دون خطأ. ماذا يعرض العمود status؟
GROUP_CONCAT(status) (أو string_agg)؛ العمود المجرّد قيمة واحدة."}],"answer":0},{"q":"أي تعبير يعطي نسبة الطلبات الملغاة من طلبات كل شهر، كنسبة مئوية؟
","options":[{"text":"COUNT(status = 'cancelled') * 100.0 / COUNT(*)","why":"COUNT يعدّ القيم غير الـ NULL، وstatus = 'cancelled' قيمته 0 أو 1 وليست NULL أبدًا، فيعدّ كل الصفوف ويعيد 100."},{"text":"100.0 * COUNT(*) FILTER (WHERE status = 'cancelled') / COUNT(*)","why":"صحيح. يقصر FILTER دالة التجميع تلك على الصفوف الملغاة؛ و100.0 يتجنّب القسمة الصحيحة."},{"text":"COUNT(*) / COUNT(*) FILTER (WHERE status = 'cancelled')","why":"هذه هي النسبة المعكوسة، ومع القسمة الصحيحة في SQLite ستُقتطع أيضًا."}],"answer":1}],"exercise":{"kind":"sql","starter":"-- Best-selling products: at least 130 units\nSELECT\n product_id,\n SUM(quantity) AS units,\n ROUND(SUM(quantity * unit_price * (1 - discount)), 2) AS revenue\nFROM order_items\nORDER BY units DESC;","solution":"SELECT\n product_id,\n SUM(quantity) AS units,\n ROUND(SUM(quantity * unit_price * (1 - discount)), 2) AS revenue\nFROM order_items\nGROUP BY product_id\nHAVING SUM(quantity) >= 130\nORDER BY units DESC, product_id;","orderMatters":false,"title":"المنتجات الأكثر مبيعًا لدى كريم","prompt":"يريد كريم كل منتج باع 130 وحدة على الأقل عبر كل سطور الطلبات (تجاهل حالة الطلب الآن).
\nأعِد صفًا واحدًا لكل منتج فيه product_id وunits (إجمالي الكمية) وrevenue (مجموع quantity * unit_price * (1 - discount) مقرّبًا إلى منزلتين عشريتين). ترتيب الصفوف لا يهم.
الكود المبدئي يعيد صفًا واحدًا. اجعله يعيد مستوى التفصيل الصحيح وطبّق الحدّ.
\n","hints":["حدّد مستوى التفصيل: صف واحد لكل منتج. أي عبارة تحقق ذلك؟","أضفGROUP BY product_id. الآن يظهر كل منتج؛ وتحتاج إلى إبقاء بعض المجموعات فقط.","الشرط على SUM(quantity) لا يمكن أن يكون في WHERE. استخدم HAVING SUM(quantity) >= 130."],"explanation":"بدون GROUP BY يجمّع SQLite الجدول كله في صف واحد ويملأ العمود المجرّد product_id من سطر اعتباطي، فيعرض الكود المبدئي منتجًا واحدًا بجانب إجمالي الشركة كلها. يضبط GROUP BY product_id مستوى التفصيل على صف واحد لكل منتج، ويصفّي HAVING هذه المجموعات بعد أن توجد المجاميع. أحد عشر منتجًا تتجاوز الحدّ. لم يبع Standing Desk 140cm (المنتج 21) إلا 132 وحدة، لكن إيراده يتجاوز 60,000، وهذا تذكير بأن عدد الوحدات والإيراد يرتّبان المنتجات بطريقتين مختلفتين جدًا.