يسأل كريم من المالية: «كم كان إيرادنا في 2025 حسب فئة المنتج؟». الإيراد موجود في order_items، والسنة في orders، واسم الفئة في categories، على بُعد خطوتين عبر products. لا يوجد جدول واحد يجيب عن السؤال. الـ JOIN يجمعها معًا، وضبطه يدور في معظمه حول معرفة الصفوف التي يُبقيها كل JOIN.
كل JOIN يحتاج إلى شرط يقول أيّ الصفوف تنتمي إلى بعضها، وهو في الغالب مفتاح: order_items.order_id يشير إلى orders.order_id، وorder_items.product_id إلى products.product_id، وهكذا. في Cartwheel يُحسب الإيراد من كل الطلبات ما عدا الملغاة.
SELECT\n c.name AS category,\n COUNT(DISTINCT o.order_id) AS orders,\n ROUND(SUM(oi.quantity * oi.unit_price * (1 - oi.discount)), 2) AS revenue\nFROM orders AS o\nJOIN order_items AS oi ON oi.order_id = o.order_id\nJOIN products AS p ON p.product_id = oi.product_id\nJOIN categories AS c ON c.category_id = p.category_id\nWHERE o.status <> 'cancelled'\n AND o.order_date >= '2025-01-01'\n AND o.order_date < '2026-01-01'\nGROUP BY c.name\nORDER BY revenue DESC;تتصدّر Desks & Chairs بنحو 77,000. لكن صفّين يبدوان غريبين: “Kitchen” و"Outdoor" فئتان في المستوى الأعلى، ويُفترض أن تقع المنتجات في فئات فرعية. احتفظ بهذه الملاحظة؛ إنها اكتشاف في جودة البيانات ستتعقّبه في القسم 4.
\nعادتان تجعلان الـ queries التي فيها JOIN مقروءة وآمنة. الأسماء المستعارة القصيرة (o، oi، p، c) تُبقي الأسطر قصيرة. ونسبة كل عمود إلى اسمه المستعار تزيل التخمين، وهذا مهم هنا: order_items.unit_price هو السعر المدفوع يوم الطلب، وproducts.unit_price هو سعر القائمة اليوم. كتابة unit_price بلا نسبة في هذا الـ query تعطي خطأ “ambiguous column name”، واختيار العمود الخطأ يغيّر الإيراد بصمت.
وCOUNT(DISTINCT o.order_id) مقصود أيضًا. بعد ربط العناصر، يظهر كل طلب مرة لكل سطر عنصر، فيعدّ COUNT(*) السطور. وهذا التكرار هو موضوع الدرس التالي.
JOIN تعني INNER JOIN: لا يبقى الصف إلا إذا وجد تطابقًا في الجانب الآخر. هذا صحيح للإيراد، حيث لا معنى لعنصر بلا طلب. لكنه خاطئ حين يكون السؤال عن كل ما في جانب واحد، بما في ذلك ما ليس له تطابق.
تطلب جوليا عدد التذاكر لكل موظف في العمليات، «بما في ذلك من لا يتولّون التذاكر، حتى أرى من يمكنه المساعدة في موسم الذروة»:
\nSELECT\n e.employee_id,\n e.first_name,\n e.title,\n COUNT(t.ticket_id) AS tickets\nFROM employees AS e\nLEFT JOIN support_tickets AS t\n ON t.agent_id = e.employee_id\nWHERE e.department = 'Operations'\nGROUP BY e.employee_id\nORDER BY tickets DESC;ثمانية صفوف. لدى كل واحد من الوكلاء الأربعة نحو 200 تذكرة؛ ولدى مارك وسمير وبن وآدم صفر. يُبقي الـ LEFT JOIN كل صف من الجدول الأيسر، وهو هنا employees، وحيث لا تطابقه أي تذكرة تكون أعمدة التذاكر NULL. يتخطّى COUNT(t.ticket_id) هذه القيم، ولهذا يظهر لغير الوكلاء 0 لا 1.
الآن تضيّق جوليا الطلب: «القائمة نفسها، لكن اعدد التذاكر العاجلة فقط». التعديل البديهي يضيف AND t.priority = 'urgent' إلى عبارة WHERE، فيختفي غير الوكلاء الأربعة. صفوفهم فيها t.priority قيمته NULL، فيكون الشرط NULL، ويحذفهم WHERE. الشرط على الجدول الأيمن في WHERE يعيد الـ LEFT JOIN إلى INNER JOIN.
مكان هذا الشرط هو عبارة ON، حيث يحدّد أي التذاكر تتطابق، لا أي الصفوف تبقى:
SELECT\n e.first_name,\n COUNT(t.ticket_id) AS urgent_tickets\nFROM employees AS e\nLEFT JOIN support_tickets AS t\n ON t.agent_id = e.employee_id\n AND t.priority = 'urgent'\nWHERE e.department = 'Operations'\nGROUP BY e.employee_id\nORDER BY urgent_tickets DESC;ثمانية صفوف من جديد، والأصفار في أماكنها. القاعدة: الشروط على الجدول الأيسر في WHERE؛ والشروط على الجدول الأيمن في ON.
\nطريقة موثوقة للقرار: ابدأ FROM بالجدول الذي تريد صفوفه في الإجابة، أي الجدول الذي يطابق مستوى التفصيل الذي كتبته. ثم اسأل عن كل جدول آخر: «هل هذه المعلومة إلزامية أم اختيارية؟». المعلومة الإلزامية تأخذ inner join، لأن الصف الذي يفتقدها لا مكان له في الإجابة. والمعلومة الاختيارية تأخذ LEFT JOIN، حتى تظهر التطابقات المفقودة كقيم NULL يمكنك عدّها أو تسميتها أو تحويلها إلى أصفار.
في قائمة جوليا تدور الإجابة حول الموظفين، فيأتي employees أولًا، والتذاكر اختيارية. وفي إيراد كريم تدور الإجابة حول المبيعات، فكل جدول في السلسلة إلزامي.
يدعم SQLite أيضًا RIGHT JOIN وFULL OUTER JOIN (منذ الإصدار 3.39)، وPostgreSQL يدعمهما منذ عقود. نادرًا ما ستحتاج إليهما: الـ right join هو left join مع تبديل الجدولين، ومعظم الفرق تكتب كل شيء بـ LEFT JOIN حتى تُقرأ الـ queries بالطريقة نفسها، من الأعلى إلى الأسفل، من الجدول الرئيسي نحو الخارج.
أخيرًا، افحص عدد الصفوف بعد كل JOIN تضيفه. إذا كان في employees بعد تصفيته على العمليات 8 صفوف، فيجب أن يعيد الـ LEFT JOIN مع GROUP BY ثمانية أيضًا. الرقم الذي يكبر أو يصغر على غير المتوقع يخبرك أن JOIN ما يفعل شيئًا لم تقصده.
كان في إيراد الفئات فخ آخر لم يُصبنا، لأن الإيراد كان في الجدول الأكثر تفصيلًا. حين يقع الرقم في الجانب الأقل تفصيلًا من الـ JOIN، تتضخّم المجاميع. وهذا هو موضوعنا التالي.
\n","toc":[{"id":"sec-1","text":"تتبّع المفاتيح","level":2},{"id":"sec-2","text":"INNER مقابل LEFT","level":2},{"id":"sec-3","text":"ON مقابل WHERE في الـ LEFT JOIN","level":2},{"id":"sec-4","text":"اختيار الـ JOIN، والجدول الذي تبدأ منه","level":2}],"takeaways":["الـ INNER JOIN لا يُبقي إلا الصفوف المتطابقة في الجانبين؛ والـ LEFT JOIN يُبقي كل صف من الجدول الأيسر ويملأ أعمدة الجانب الأيمن غير المطابقة بـ NULL.","أعطِ كل جدول اسمًا مستعارًا قصيرًا وانسب إليه كل عمود، خاصةً الأسماء الموجودة في أكثر من جدول مثل unit_price.","الشرط على الجدول الأيمن في LEFT JOIN مكانه عبارة ON؛ أما في WHERE فيحذف صفوف NULL ويعيد الـ JOIN إلى inner join.","بعد LEFT JOIN اعدد عمودًا من الجدول الأيمن لا *، حتى تُحسب الصفوف غير المطابقة 0 لا 1."],"further":[{"title":"SQLite SELECT, the FROM clause and joins","url":"https://www.sqlite.org/lang_select.html#fromclause"},{"title":"PostgreSQL tutorial on joins between tables","url":"https://www.postgresql.org/docs/current/tutorial-join.html"}],"quiz":[{"q":"في orders يوجد 2,066 صفًا وفي order_items يوجد 3,991. لكل طلب عنصر واحد على الأقل. كم صفًا يعيد orders o JOIN order_items oi ON oi.order_id = o.order_id؟
يُفترض أن يعرض هذا كل عميل في المملكة المتحدة مع عدد طلباته من الـ marketplace، بما فيها الصفر. لماذا يختفي العملاء الذين ليس لديهم طلبات من الـ marketplace؟
\nSELECT c.customer_id, COUNT(o.order_id) AS marketplace_orders\nFROM customers c\nLEFT JOIN orders o ON o.customer_id = c.customer_id\nWHERE c.country = 'United Kingdom'\n AND o.channel = 'marketplace'\nGROUP BY c.customer_id;COUNT(o.order_id) هو COUNT(*).","why":"تعبير العدّ ليس المشكلة؛ العملاء المفقودون لا يصلون إلى GROUP BY أصلًا."},{"text":"اختبار o.channel قيمته NULL للعملاء الذين ليس لهم طلب مطابق، فيحذفهم WHERE.","why":"صحيح. انقل AND o.channel = 'marketplace' إلى عبارة ON؛ ويبقى اختبار الدولة في WHERE لأنه يخص الجدول الأيسر."},{"text":"الـ LEFT JOIN لا يُبقي إلا الصفوف غير المطابقة من الجدول الأيمن.","why":"العكس هو الصحيح. يحتفظ الـ LEFT JOIN بكل صف من الجدول الأيسر، وهو هنا customers."}],"answer":1},{"q":"يفشل SELECT unit_price FROM order_items oi JOIN products p ON p.product_id = oi.product_id. لماذا؟
unit_price موجود في الجدولين، فالاسم ملتبس.","why":"صحيح. اكتب oi.unit_price (السعر المدفوع) أو p.unit_price (سعر القائمة). وهما رقمان مختلفان بعد رفع الأسعار في مارس 2025."},{"text":"لا يمكنك اختيار عمود استُخدم في JOIN.","why":"يمكن اختيار أي عمود؛ ومفتاح الـ JOIN ليس طرفًا هنا أصلًا."},{"text":"الأسماء المستعارة يجب أن تُعرَّف بـ AS.","why":"AS اختيارية للأسماء المستعارة للجداول في SQLite وPostgreSQL."}],"answer":0},{"q":"بعد employees e LEFT JOIN support_tickets t ON t.agent_id = e.employee_id، أي تعبير يعطي 0 تذاكر للموظفين الذين لم يتولّوا أي تذكرة؟
COUNT(*)","why":"الموظف غير المطابق ما زال ينتج صفًا واحدًا (بأعمدة تذاكر قيمتها NULL)، فيعيد COUNT(*) القيمة 1."},{"text":"COUNT(e.employee_id)","why":"معرّف الموظف ليس NULL أبدًا، فهذا أيضًا يعدّ الصف غير المطابق 1."},{"text":"COUNT(t.ticket_id)","why":"صحيح. معرّف التذكرة قيمته NULL في الصف غير المطابق، وCOUNT يتخطّى NULL."},{"text":"SUM(t.ticket_id)","why":"هذا يجمع أرقام المعرّفات، وهو بلا معنى، ويعيد NULL للموظفين غير المطابقين."}],"answer":2}],"exercise":{"kind":"sql","starter":"-- Every Jordan customer with their 2025 orders (zero included)\nSELECT\n c.customer_id,\n c.first_name,\n COUNT(o.order_id) AS orders_2025\nFROM customers AS c\nLEFT JOIN orders AS o\n ON o.customer_id = c.customer_id\nWHERE c.country = 'Jordan'\n AND o.status <> 'cancelled'\n AND o.order_date >= '2025-01-01'\n AND o.order_date < '2026-01-01'\nGROUP BY c.customer_id;","solution":"SELECT\n c.customer_id,\n c.first_name,\n COUNT(o.order_id) AS orders_2025\nFROM customers AS c\nLEFT JOIN orders AS o\n ON o.customer_id = c.customer_id\n AND o.status <> 'cancelled'\n AND o.order_date >= '2025-01-01'\n AND o.order_date < '2026-01-01'\nWHERE c.country = 'Jordan'\nGROUP BY c.customer_id, c.first_name;","orderMatters":false,"title":"كل عملاء الأردن، بما فيهم الأصفار","prompt":"تخطّط هدى لرسالة بريد لاستعادة العملاء في الأردن، وتحتاج إلى كل عميل في الأردن مع عدد الطلبات غير الملغاة التي قدّمها في 2025، مع إظهار 0 لمن لم يطلب.
\nأعِد customer_id وfirst_name وorders_2025. ترتيب الصفوف لا يهم. في الأردن 32 عميلًا، فتوقّع 32 صفًا؛ والكود المبدئي يعيد أقل من ذلك.
o.status وo.order_date لديهم بعد الـ LEFT JOIN؟","الشروط على الجدول الأيمن (orders) تحدّد أي الطلبات تتطابق. ومكانها عبارة ON.","أبقِ c.country = 'Jordan' في WHERE (لأنه يخص الجدول الأيسر)، وانقل اختباري الحالة والتاريخ إلى ON ... AND ...."],"explanation":"لعميل في الأردن ليس لديه طلبات في 2025، ينتج الـ LEFT JOIN صفًا واحدًا كل أعمدة o. فيه NULL. في الكود المبدئي تكون قيمة o.status <> 'cancelled' لهذا الصف NULL، فيرميه WHERE ويختفي العميل. نقل شروط الطلبات إلى ON يعني أنها تحدّد فقط أي الطلبات تُرفق؛ ويبقى صف العميل في الحالتين، ويعدّ COUNT(o.order_id) له 0. تسعة عملاء لم يطلبوا شيئًا في 2025، وهم بالضبط من تستهدفهم رسالة الاستعادة.