يطرح كريم سؤالًا يخفي في داخله سؤالًا ثانيًا: «أي العملاء أنفقوا أكثر من العميل المتوسط في 2025؟». للإجابة تحتاج إلى المتوسط أولًا، وهذا بدوره يحتاج إلى الإيراد لكل عميل. إنها ثلاث خطوات: الإيراد لكل عميل، ثم متوسطه، ثم المقارنة. يعطيك SQL طريقتين لتداخل الخطوات، الـ subqueries والـ CTEs، والاختيار بينهما يحدّد هل يستطيع المحلّل التالي أن يقرأ عملك.
\nاستخدمت اثنين منها بالفعل. الجدول المشتق subquery داخل FROM يتصرّف كجدول (الإيراد لكل طلب الذي أصلح الـ fan-out). والـ subquery المترابط يشير إلى الصف الخارجي ويعمل لكل صف (الـ anti-join بـ NOT EXISTS). والثالث هو الـ scalar subquery: query يعيد قيمة واحدة بالضبط، ويمكن استخدامه في أي مكان تصلح فيه قيمة.
\nهذا سؤال كريم مكتوبًا بالتداخل وحده:
\nSELECT COUNT(*) AS above_average_customers\nFROM (\n SELECT o.customer_id, SUM(oi.quantity * oi.unit_price * (1 - oi.discount)) AS revenue\n FROM orders AS o\n JOIN order_items AS oi ON oi.order_id = o.order_id\n WHERE o.status <> 'cancelled'\n AND o.order_date >= '2025-01-01' AND o.order_date < '2026-01-01'\n GROUP BY o.customer_id\n) AS r\nWHERE r.revenue > (\n SELECT AVG(revenue) FROM (\n SELECT SUM(oi.quantity * oi.unit_price * (1 - oi.discount)) AS revenue\n FROM orders AS o\n JOIN order_items AS oi ON oi.order_id = o.order_id\n WHERE o.status <> 'cancelled'\n AND o.order_date >= '2025-01-01' AND o.order_date < '2026-01-01'\n GROUP BY o.customer_id\n )\n);إنه يعمل: 140 عميلًا. لكنه صعب القراءة أيضًا، ومنطق الإيراد مكتوب فيه مرتين. حين يغيّر أحدهم تعريف الإيراد في الربع القادم، سيحدّث نسخة وينسى الأخرى.
\nالـ CTE (common table expression) يسمّي query باستخدام WITH name AS (...)، وتشير إليه الخطوات اللاحقة كما تشير إلى جدول:
WITH revenue_2025 AS (\n -- grain: one row per customer who bought in 2025\n SELECT o.customer_id,\n SUM(oi.quantity * oi.unit_price * (1 - oi.discount)) AS revenue\n FROM orders AS o\n JOIN order_items AS oi ON oi.order_id = o.order_id\n WHERE o.status <> 'cancelled'\n AND o.order_date >= '2025-01-01' AND o.order_date < '2026-01-01'\n GROUP BY o.customer_id\n),\nbenchmark AS (\n SELECT AVG(revenue) AS avg_revenue FROM revenue_2025\n)\nSELECT\n COUNT(*) AS buyers,\n SUM(r.revenue > b.avg_revenue) AS above_average,\n ROUND(b.avg_revenue, 2) AS avg_revenue\nFROM revenue_2025 AS r\nCROSS JOIN benchmark AS b;الآن يُقرأ التحليل كالجملة التي يجيب عنها: الإيراد لكل عميل، ثم المعيار، ثم المقارنة. الإيراد معرّف مرة واحدة. وأثناء البناء يمكنك استبدال الـ SELECT الأخير بـ SELECT * FROM revenue_2025 LIMIT 5 لتفحص أي خطوة، وهذه أفضل عادة منفردة لتصحيح الـ SQL الطويل. والـ CROSS JOIN آمن هنا لأن في benchmark صفًا واحدًا بالضبط. في SQLite تكون المقارنة 1 أو 0، فيعدّ SUM(condition) الصفوف التي قيمتها TRUE؛ وفي PostgreSQL ستكتب COUNT(*) FILTER (WHERE ...).
إذن 140 من أصل 418 مشتريًا يقعون فوق المتوسط البالغ 781.84. هذا معتاد في بيانات الإيرادات: أقلية من العملاء الكبار ترفع المتوسط، ولهذا ستعرض الوسيط بجانبه في كثير من الأحيان.
\n\nيعود طلب رانيا الخاص بإعادة الهيكلة: «اعرض كل من في فريق الهندسة الذي يقوده بيتر ويبر، على أي مستوى، مع بُعد كل شخص عنه». الـ self-join يعطيك مستوى واحدًا. فريق بيتر فيه مستويان، وقد يكون في قسم آخر خمسة. الـ CTE التكراري يتعمّق بقدر ما تتعمّق البيانات:
\nWITH RECURSIVE org AS (\n -- anchor: where the walk starts\n SELECT employee_id, first_name, title, 0 AS depth, first_name AS path\n FROM employees\n WHERE employee_id = 4\n UNION ALL\n -- recursive step: people who report to anyone found so far\n SELECT e.employee_id, e.first_name, e.title, org.depth + 1,\n org.path || ' > ' || e.first_name\n FROM employees AS e\n JOIN org ON e.manager_id = org.employee_id\n)\nSELECT depth, path, title\nFROM org\nORDER BY path;البنية هي نفسها دائمًا. query الارتكاز يعمل مرة واحدة وينتج صفوف البداية. والـ query التكراري يربط employees بـ org نفسه، لكنه في كل تكرار لا يرى إلا الصفوف التي أضافها التكرار السابق. كل جولة تضيف المستوى التالي نزولًا، وينتهي التتبّع حين لا يجد تكرارٌ أحدًا.
يُمرَّر depth وpath عبر التكرار: كل صف جديد يحسب قيمه من الصف الأب الذي ارتبط به. والترتيب حسب path يطبع النتيجة كشجرة متدرّجة. يصلح النمط نفسه لتجميع التكاليف صعودًا في شجرة فئات، أو لتتبّع سلاسل الإحالة، أو لتفكيك قائمة مكوّنات منتج.
بالـ CTEs تستطيع أن تسمّي كل خطوة. يضيف الدرس التالي أداة تتيح لكل صف أن يرى جيرانه دون ضغط أي شيء: دوال النافذة.
\n","toc":[{"id":"sec-1","text":"ثلاثة أنواع من الـ subqueries","level":2},{"id":"sec-2","text":"التحليل نفسه بالـ CTEs","level":2},{"id":"sec-3","text":"الـ CTE التكراري: تتبّع تسلسل هرمي","level":2}],"takeaways":["الـ scalar subquery يعيد قيمة واحدة ويمكن وضعه في أي مكان تصلح فيه قيمة، مثل المقارنة بمتوسط عام.","الـ CTE (أي WITH name AS …) يسمّي نتيجة وسيطة، فيُقرأ التحليل الطويل من الأعلى إلى الأسفل ويمكن فحص كل خطوة وحدها.","الـ CTE التكراري فيه query ارتكاز، ثم UNION ALL، ثم query تكراري يرتبط بالـ CTE نفسه؛ ويتوقف حين لا يضيف أي تكرار صفوفًا جديدة.","مرّر عدّادًا للعمق (ومسارًا إن كان مفيدًا) عبر التكرار، وضع حدًّا للعمق حين يُحتمل أن تحتوي البيانات على حلقة."],"further":[{"title":"SQLite WITH clause and recursive common table expressions","url":"https://www.sqlite.org/lang_with.html"},{"title":"PostgreSQL WITH queries","url":"https://www.postgresql.org/docs/current/queries-with.html"}],"quiz":[{"q":"أيّها scalar subquery مستخدم بشكل صحيح؟
","options":[{"text":"WHERE revenue > (SELECT revenue FROM revenue_2025)","why":"هذا الـ subquery يعيد صفًا لكل عميل. يستخدم SQLite الصف الأول بصمت؛ ويرمي PostgreSQL خطأً. وفي الحالتين ليس هذا هو المتوسط."},{"text":"FROM (SELECT AVG(revenue) FROM revenue_2025) بلا اسم مستعار ولا ربط","why":"هذا جدول مشتق لا scalar subquery، ولا يرتبط وحده بالعملاء الذين تصفّيهم."},{"text":"WHERE customer_id = (SELECT customer_id FROM orders)","why":"كالخيار الأول، يعيد الـ subquery صفوفًا كثيرة حيث يُتوقّع قيمة واحدة."},{"text":"WHERE revenue > (SELECT AVG(revenue) FROM revenue_2025)","why":"صحيح. دالة التجميع بلا GROUP BY تعيد صفًا واحدًا وعمودًا واحدًا بالضبط، فتحلّ محل قيمة واحدة."}],"answer":3},{"q":"ما السبب الرئيسي الذي يدفع المحلّلين إلى إعادة بناء query متداخل في صورة CTEs؟
","options":[{"text":"تأخذ كل خطوة اسمًا ويُقرأ الـ query من الأعلى إلى الأسفل، ويمكنك تشغيل أي خطوة وحدها لفحصها.","why":"صحيح. المنطق نفسه؛ ما يتحسّن هو المقروئية وقابلية الفحص."},{"text":"الـ CTEs أسرع دائمًا من الـ subqueries.","why":"كثيرًا ما تدمج المحرّكات الـ CTEs وتخطّط لها كما تخطّط للـ subqueries، فيكون الأداء متشابهًا عادةً. اختر الـ CTEs من أجل الوضوح."},{"text":"الـ subqueries لا يمكن أن تحتوي على دوال تجميع، أما الـ CTEs فيمكن.","why":"يمكن للـ subqueries أن تجمّع؛ وإصلاح الـ fan-out في القسم السابق فعل ذلك بالضبط."}],"answer":0},{"q":"يبدأ CTE تكراري من المديرة التنفيذية ويربط employees e ON e.manager_id = org.employee_id. متى يتوقف؟
manager_id لديه NULL.","why":"المديرة التنفيذية هي صف الارتكاز، حيث يبدأ التتبّع. يسير التتبّع نزولًا وينتهي عند أشخاص لا يتبع لهم أحد."},{"text":"حين لا ينتج تكرارٌ أي صفوف جديدة، لأن المستوى الأخير لا يتبع له أحد.","why":"صحيح. كل تكرار لا يربط إلا الصفوف الناتجة عن التكرار السابق؛ وحين لا يتبع أحد لأي شخص في تلك المجموعة، ينتهي التكرار."},{"text":"حين يُبلغ حدّ عبارة LIMIT.","why":"لا يوجد LIMIT في جسم الـ CTE هنا. يمكن لـ LIMIT أن يحدّ التكرار، لكن التوقف الطبيعي هو تكرار فارغ."}],"answer":2},{"q":"لماذا تضيف شرطًا مثل WHERE org.depth < 20 إلى query تكراري على customers.referred_by؟
يحتاج مارك إيفانز (نائب الرئيس للعمليات، employee_id = 2) إلى فريقه كاملًا لتخطيط عدد الموظفين: كل من يتبع له مباشرةً أو بشكل غير مباشر، دون مارك نفسه.
أعِد employee_id وfirst_name وdepth (1 لمن يتبعون له مباشرةً، و2 لمن يتبعون لهؤلاء، وهكذا)، مرتّبة حسب depth ثم employee_id. الترتيب مهم.
الارتكاز في الكود المبدئي صحيح بالفعل، لكنه يتوقف عند التابعين المباشرين. أضف الخطوة التكرارية.
\n","hints":["الـ CTE التكراري يحتاج إلىUNION ALL يتبعه SELECT ثانٍ يرتبط بـ org.","اربط employees AS e بـ org على e.manager_id = org.employee_id: الأشخاص الذين مديرهم شخص وُجد بالفعل.","اختر e.employee_id, e.first_name, org.depth + 1 في الخطوة التكرارية حتى يكون كل مستوى أعمق بدرجة من أبيه."],"explanation":"يجد الارتكاز التابعين المباشرين الثلاثة لمارك (سمير وجوليا وآدم) على العمق 1. ثم تضيف الخطوة التكرارية مرة بعد مرة الأشخاص الذين يقع مديرهم في التكرار السابق: أخصائيو الدعم الثلاثة تحت جوليا، وبن تحت سمير، على العمق 2. لا يجد التكرار التالي أحدًا يتبع لهؤلاء الأربعة، فيتوقف التكرار بسبعة أشخاص. بدء الارتكاز من manager_id = 2 بدل مارك نفسه هو ما يُبقيه خارج النتيجة.