تجاوز إلى المحتوى
تعلّم لعملك المرجع مقالات المحفوظات
العربية

playbook

اكتب الـ query وتعلّم الـ SQL

احصل على الـ query الدقيق للسؤال الذي بين يديك فعلًا، وعلى شرح سطرًا بسطر بلغة واضحة لكل clause، وعلى مراجعةٍ مقابل إجمالي معروف — الإجابة والفهم الذي تدافع به عنها.

متوسّط ~40 دقيقة

متى تلجأ إلى هذا

أنت بحاجة إلى رقم — المستخدمون النشطون شهريًا حسب الـ plan، أو الإيرادات حسب الـ region، أو أيًّا كان ما طلبه مديرك للتوّ — وتعرف تقريبًا ما هو الـ SQL لكن ليس بما يكفي لكتابته من الصفر، أو لتثق بـ query يسلّمه لك أحدهم. نسخ ولصق query لا تفهمه هو الطريق إلى أن ينتهي رقم خاطئ في عرضٍ تقديمي يحمل اسمك. هذا النظام يوصلك إلى الـ query، وإلى شرح يعلّمك ما يفعله كل clause، وإلى خطوة مراجعة — حتى تتمكن من إنتاج الإجابة وشرحها حين يعترض عليها أحد.

جهّز هذا أولًا

  • الـ schema أو عيّنة منه: اسم الـ table وأعمدته — الصق الـ CREATE TABLE أو ملف schema.sql، أو فقط بضعة صفوف مثال من events.csv.
  • السؤال في جملة واضحة واحدة («المستخدمون النشطون حسب الـ plan، آخر 6 أشهر») وكيف ستعرّف الكلمات المبهمة فيه — ما الذي يُعدّ 'نشطًا'، وأين تقع حدود الشهر.
  • إجمالي معروف لتراجع عليه — عدد صفوف من profile درس *استجوب الـ dataset قبل أن تلمسه*، أو رقم من تقرير الشهر الماضي.

الـ workflow

  1. صُغ السؤال بدقّة قبل أي SQL

    معظم الـ queries الخاطئة تأتي من سؤال مبهم، لا من syntax سيّئ. اجعل Claude يحدّد التعريفات أولًا — 'نشط' و'آخر 6 أشهر' لا تعني شيئًا حتى تتفقا عليها — حتى يجيب الـ query عن السؤال الذي بين يديك فعلًا.

    أنت تطلب 
    أريد عدد المستخدمين النشطين شهريًا حسب الـ plan لآخر 6 أشهر من الـ table المسمّى events. قبل أن تكتب أي SQL، أعِد عليّ صياغة الطلب: كيف تعرّف 'active'، وأين يبدأ كل شهر وينتهي، وأي timezone؟ واسرد أي افتراض تأخذ به. لا تكتب الـ query بعد.

    ما تحصل عليه إعادة قراءة قصيرة: «active = حدثٌ واحد على الأقل في الشهر؛ الأشهر هي أشهر تقويمية بتوقيت UTC؛ آخر 6 تعني يناير–يونيو». وإن كان المقصود بـ 'active' هو *login* لا أي حدث، فأنت تصحّح ذلك هنا — قبل أن يُخبز داخل الـ query.

    خطوة 'أعِد قراءة السؤال عليّ أولًا' هذه هي اللعبة كلها. الـ query الذي يجيب عن السؤال الخطأ يعمل بإتقان ويكذب بثقة.

  2. احصل على الـ query مع شرح سطرًا بسطر

    اطلب الـ SQL والشرح في نفسٍ واحد. الشرح هو ما يحوّل هذا من نسخ-ولصق إلى شيء تفهمه بما يكفي لتعديله والدفاع عنه.

    أنت تطلب 
    اكتب الآن الـ query لذلك. ثم اشرحه لي clause تلو clause بلغة واضحة: ماذا يفعل فلتر الـ WHERE، وماذا يجمع GROUP BY plan, month معًا، ولماذا استخدمت دالّة التاريخ تلك، وماذا يعني كل column في الـ output. افترض أنني لست خبيرًا في الـ SQL.

    ما تحصل عليه الـ query، ثم شرح مرقّم: «WHERE event_date >= '2026-01-01' يُبقي آخر 6 أشهر فقط؛ GROUP BY plan, month يصنع صفًا واحدًا لكل plan في كل شهر؛ COUNT(DISTINCT user_id) يَعُدّ كل مستخدم مرة واحدة حتى لو أطلق عشرة أحداث». تخرج وأنت تعرف لماذا، لا ماذا فقط.

  3. راجع النتيجة مقابل إجمالي معروف

    الرقم الذي لا تستطيع تتبّعه رجوعًا إلى شيء تثق به أصلًا هو رقم لا تستطيع مشاركته. اربط مخرَج الـ query بعدد الصفوف أو بتقرير سابق قبل أن تصدّقه.

    أنت تطلب 
    شغّله وأظهر لي النتيجة. ثم راجِع: هل مجموع المستخدمين عبر كل الـ plans والأشهر يتوافق مع عدد المستخدمين المتمايزين في الـ table الخام؟ إن لم يتطابقا، فجِد الفجوة — فلتر يُسقِط صفوفًا، أو plan بقيمة NULL، أو قيمة مكرّرة — وأخبرني أيُّها.

    ما تحصل عليه جدول النتيجة إضافة إلى مراجعة: «14,210 مستخدمًا متمايزًا إجمالًا، يطابق الـ table الخام — باستثناء 38 صفًا تحمل plan بقيمة NULL واستُبعدت؛ إليك العدّ بها وبدونها». الآن صار الرقم قابلًا للدفاع عنه، بكل حالاته الحدّية.

    راجع مقابل إجمالي *معروف* — عدد صفوف أو رقم الشهر الماضي. النتيجة التي لا تطابق شيئًا تثق به أصلًا هي مجرد تخمين واثق.

  4. اختبر الحواف بالضغط واحفظ النسخة المشروحة

    اجعل Claude يهاجم query الخاص به بحثًا عن الحالات التي تكسر الإجماليات بهدوء — المكرّرات، وقيم NULL، وحدود الـ timezone — ثم احتفظ بالنسخة المعلَّق عليها كي يستطيع نفسُك المستقبلي (ومراجِعٌ) قراءتها.

    أنت تطلب 
    ما الذي قد يجعل هذا الـ query خاطئًا دون أن تكشفه النتيجة؟ افحص العدّ المزدوج، وقيم NULL في الـ GROUP BY، وحدود الأشهر التي تخطئ بمقدار واحد، وحالات الـ timezone الحدّية. ثم أعطني الـ query النهائي مع تعليق من سطر واحد فوق كل clause يشرحه، جاهزًا للحفظ باسم active-users.sql.

    ما تحصل عليه قائمة مخاطر قصيرة («مستخدم بدّل الـ plan يُحتسب تحت كليهما — هل هذا مقصود؟») وملف active-users.sql معلَّق عليه يمكنك إعادة قراءته بعد ثلاثة أشهر وما زلت تفهمه.

اجعله ملكك

  • **جدول بيانات، لا database:** نفس التدفّق على CSV — يستطيع Claude حساب الإجابة مباشرةً فوق events.csv وما زال يشرح كل خطوة؛ لا تحتاج database حيّة لتتعلّم المنطق.
  • **تحرّك الرقم ولا تعرف لماذا:** حين يكون السؤال 'لماذا تغيّر هذا'، سلّم الـ query المشروح مباشرةً إلى *اكتشف لماذا تحرّك الرقم* — كون الـ query مفهومًا أصلًا يجعل مطاردة السبب الجذري أسرع بكثير.
  • **query تشغّله كل شهر:** بمجرد أن يُشرَح ويُراجَع، احفظ الـ prompt كـ /mau custom command أو كـ skill (انظر تبويب *Features*) حتى يعود الرقم المتكرّر بالطريقة نفسها في كل مرة — الأساس الذي يتّكئ عليه capstone درس *ابنِ تقرير تحليل متكرّرًا*.

انتبه إلى

  • قد يكون الـ query سليم الـ syntax تمامًا ويجيب عن السؤال الخطأ. إعادة القراءة في الخطوة 1 غير قابلة للتفاوض — تحقّق من *تعريف* كل كلمة مبهمة ('active'، 'churned'، 'month') قبل أن تثق بالـ output.
  • إن كان الـ table يحوي بيانات شخصية، شغّل الـ query محليًا وشارك الإجمالي فقط. الصق schema وبضعة صفوف عيّنة كلما أمكن بدل إفراغ table خام مليء بالـ emails داخل الـ prompt.
  • يكتب Claude الـ query ويشرحه؛ وأنت تملك ما إذا كانت الإجابة صحيحة. اقرأ الشرح، وراجع الإجمالي، وأكّد أن المنطق يطابق قصدك — لا تسلّم رقمًا لا تستطيع شرحه بصوتٍ عالٍ.

ستحصل في النهاية على الـ query الدقيق لسؤالك الحقيقي، وشرح بلغة واضحة علّمك لماذا يعمل، ومراجعة تُثبت الرقم، وملف `.sql` معلَّق عليه يمكنك إعادة تشغيله والدفاع عنه.