يرسل كريم من المالية سؤالًا سريعًا: «في 2025، حسب القناة، كم جمعنا من رسوم الشحن، وكم من إيراد العناصر؟». أنت تعرف الـ JOIN المطلوب. وهذا هو الـ query الذي يكتبه معظم الناس أولًا:
\nSELECT\n o.channel,\n ROUND(SUM(o.shipping_fee), 2) AS shipping,\n ROUND(SUM(oi.quantity * oi.unit_price * (1 - oi.discount)), 2) AS item_revenue\nFROM orders AS o\nJOIN order_items AS oi ON oi.order_id = o.order_id\nWHERE o.status <> 'cancelled'\n AND o.order_date >= '2025-01-01'\n AND o.order_date < '2026-01-01'\nGROUP BY o.channel;إيراد العناصر صحيح. أما الشحن فيقارب ضعف ما يجب: يعرض الويب 6,732 بينما الرقم الحقيقي 3,413. لم يظهر أي خطأ، ولا شيء يبدو سخيفًا من النظرة الأولى. هذا هو الـ fan-out (تضاعف الصفوف)، أغلى خطأ في التحليل ثمنًا، لأنه ينتج أرقامًا قابلة للتصديق.
\nبين orders وorder_items علاقة واحد-إلى-متعدد: طلب واحد، وسطر واحد أو أكثر. حين تربطهما، يكون في النتيجة صف لكل سطر، ويحمل كل سطر نسخة من أعمدة طلبه، بما فيها shipping_fee.
نجا إيراد العناصر لأنه يقع في جانب «المتعدد»: إيراد كل سطر يظهر مرة واحدة بالضبط. أما الشحن فيقع في جانب «الواحد»، فيُحسب مرة لكل سطر. متوسط عدد السطور في طلبات Cartwheel هو 1.93، ولهذا تضاعف الشحن تقريبًا.
\nالقاعدة العامة: الـ JOIN يغيّر مستوى التفصيل إلى مستوى تفصيل أكثر جداوله تفصيلًا، وأي رقم مخزّن بمستوى تفصيل أخشن يتكرّر.
\nأوصل كل جدول إلى مستوى تفصيل الإجابة قبل الربط. هنا، اضغط order_items في صف واحد لكل طلب داخل subquery، ثم اربط النتيجة بـ orders. الآن في الجانبين صف واحد لكل طلب، ولا يتكرّر شيء:
SELECT\n o.channel,\n COUNT(*) AS orders,\n ROUND(SUM(o.shipping_fee), 2) AS shipping,\n ROUND(SUM(i.revenue), 2) AS item_revenue\nFROM orders AS o\nJOIN (\n SELECT order_id, SUM(quantity * unit_price * (1 - discount)) AS revenue\n FROM order_items\n GROUP BY order_id\n) AS i ON i.order_id = o.order_id\nWHERE o.status <> 'cancelled'\n AND o.order_date >= '2025-01-01'\n AND o.order_date < '2026-01-01'\nGROUP BY o.channel;الـ subquery داخل FROM (ويُسمّى جدولًا مشتقًّا) يتصرّف كجدول مؤقت بمستوى التفصيل الذي اخترته، وهو هنا صف واحد لكل order_id. الشحن الآن يطابق query على orders وحده، وإيراد العناصر لم يتغيّر، وCOUNT(*) يعدّ الطلبات، لأن الصفوف عادت طلبات. سيعرض القسم التالي طريقة أرتب لكتابة الشيء نفسه باستخدام WITH.
الـ fan-out يتراكم. تسأل جوليا كم إيرادًا جاء من طلبات احتاجت إلى تذكرة دعم. اربط العناصر والتذاكر بالطلبات نفسها، فيتكرّر كل سطر مرة لكل تذكرة على طلبه؛ و110 طلبات لديها أكثر من تذكرة واحدة. المجموع الساذج يقول 166,562. أما الإجابة الصحيحة، التي تسأل هل توجد تذكرة بدل ربط كل تذكرة، فهي 140,675:
\nSELECT ROUND(SUM(quantity * unit_price * (1 - discount)), 2) AS revenue_with_tickets\nFROM order_items\nWHERE order_id IN (SELECT order_id FROM support_tickets);IN (subquery) يصفّي دون ربط، فلا يمكن أن يضاعف الصفوف أبدًا. هذا النمط، «هل يوجد تطابق؟»، ويُسمّى semi-join، يحظى بشرح كامل في الدرس التالي مع نقيضه.
لا داعي لأن تنتظر مجموعًا خاطئًا. قبل الربط، اسأل عن كل مفتاح ربط: هل هو فريد في هذا الجانب؟ order_id فريد في orders (فهو المفتاح الأساسي) لكنه ليس فريدًا في order_items ولا في support_tickets، فربط أيٍّ منهما بـ orders يضاعف صفوف الطلبات. فحص سريع يخبرك بذلك:
SELECT\n COUNT(*) AS rows_after_join,\n COUNT(DISTINCT order_id) AS distinct_orders\nFROM order_items;3,991 صفًا مقابل 2,066 طلبًا: معامل تضاعف يقارب الاثنين. حين يختلف هذان الرقمان، فأي عمود تجمعه من جانب «الواحد» يحتاج إلى تجميع مسبق أو إلى إبعاده عن الـ JOIN. وحين يتساويان، يكون الـ JOIN واحد-إلى-واحد وآمنًا للجمع من أي جانب.
\nفي كل مرة تربط فيها جداول، طابِق مجموعًا واحدًا على الأقل مع نسخة من جدول واحد. الشحن حسب القناة من الـ query المربوط يجب أن يساوي الشحن حسب القناة من orders وحده؛ وإيراد العناصر يجب أن يساوي المجموع على order_items للطلبات نفسها. إذا تطابقا، فالـ JOIN لم يضاعف شيئًا. وإذا لم يتطابقا، فقد أمسكت بالخطأ قبل أن يصل إلى عرض كريم أمام مجلس الإدارة.
في الدرس التالي ستربط الجدول بنفسه، وتبحث عن صفوف لا تطابق لها على الإطلاق.
\n","toc":[{"id":"sec-1","text":"من أين يأتي المال الإضافي","level":2},{"id":"sec-2","text":"الإصلاح: جمّع أولًا، ثم اربط","level":2},{"id":"sec-3","text":"تضاعفان في آن واحد","level":2},{"id":"sec-4","text":"اكتشاف الـ fan-out قبل أن يصيبك","level":2},{"id":"sec-5","text":"عادة المطابقة","level":2}],"takeaways":["ربط علاقة واحد-إلى-متعدد يعطي النتيجة مستوى تفصيل جانب «المتعدد»، ويكرّر كل عمود من جانب «الواحد».","جمع عمود من الجانب المتكرّر، مثل رسوم شحن الطلب بعد ربطه بالعناصر، يحسبه مرة لكل صف مطابق.","جمّع جانب «المتعدد» أولًا إلى مستوى تفصيل جانب «الواحد» داخل subquery، ثم اربط، حتى يُحسب كل رقم مرة واحدة بالضبط.","قد ينقذ COUNT(DISTINCT key) عدًّا ما، لكن SUM(DISTINCT value) ليس إصلاحًا أبدًا لأنه يدمج أيضًا صفوفًا مختلفة تتشارك القيمة نفسها.","طابِق كل مجموع بعد الـ JOIN مع المجموع نفسه محسوبًا من جدوله وحده."],"further":[{"title":"SQLite SELECT, subqueries in the FROM clause","url":"https://www.sqlite.org/lang_select.html#fromclause"},{"title":"PostgreSQL table expressions and subqueries in FROM","url":"https://www.postgresql.org/docs/current/queries-table-expressions.html"}],"quiz":[{"q":"رسوم شحن الطلب 1001 هي 7.99 وفيه أربعة سطور عناصر. بعد ربط orders بـ order_items، كم يساهم SUM(o.shipping_fee) من هذا الطلب؟
يصلح زميلك مجموع شحن متضخّمًا بكتابة SUM(DISTINCT o.shipping_fee). ما الخطأ في ذلك؟
تحتاج إلى إيراد العناصر وعدد التذاكر لكل طلب. في order_items وsupport_tickets كليهما صفوف كثيرة لكل طلب. ما الطريقة الأكثر أمانًا؟
يريد كريم التقسيم نفسه حسب دولة العميل لعام 2025 (الطلبات غير الملغاة): country، وorders (عدد الطلبات)، وshipping_total (مجموع shipping_fee مقرّبًا إلى منزلتين عشريتين)، وitem_revenue (مقرّبًا إلى منزلتين عشريتين). ترتيب الصفوف لا يهم.
إيراد العناصر في الكود المبدئي صحيح، لكن أعداد الطلبات ومجاميع الشحن متضخّمة. أصلح مستوى التفصيل.
\n","hints":["أي جدول هو جانب «المتعدد»؟ بعد ربطه، ماذا يمثّل الصف الواحد، وكم مرة يظهرshipping_fee لكل طلب؟","استبدل الربط بـ order_items بربط بـ subquery يعيد صفًا واحدًا لكل order_id مع إيراده.","داخل الـ subquery: SELECT order_id, SUM(quantity * unit_price * (1 - discount)) AS revenue FROM order_items GROUP BY order_id. ثم اجمع i.revenue خارجه."],"explanation":"ربط order_items يحوّل كل طلب إلى صف لكل سطر، فعدّ COUNT(*) السطور، وحسب SUM(o.shipping_fee) كل رسوم مرة لكل سطر. ضغط العناصر أولًا في صف واحد لكل طلب يجعل كل ربط واحد-إلى-واحد بمستوى تفصيل الطلب، فتُحسب الطلبات والرسوم مرة واحدة ويبقى إيراد العناصر كما هو. تتصدّر المملكة المتحدة بـ 241 طلبًا ونحو 58,000 من إيراد العناصر. سيصلح COUNT(DISTINCT o.order_id) العدد أيضًا، لكن لا توجد حيلة DISTINCT تصلح مجموع الشحن.