يارا، المحلّلة الأقدم في فريقك، تراجع كل query قبل أن يصل إلى صاحب الطلب. نادرًا ما يكون تعليقها الأول على عمل المحلّلين الجدد عن المنطق. إنه «لا أستطيع فحص هذا بسرعة». أما تعليقها الثاني هذا الربع فعملي: Cartwheel تنقل تقاريرها إلى مستودع بيانات على PostgreSQL، وكل query كتبته يجب أن ينجو من هذا الانتقال. يغطي هذا الدرس الأمرين: SQL يستطيع المراجعون قراءته، وSQL ينتقل بين المحرّكات.
\nهذا query حقيقي من لوحة المعلومات القديمة لفريق الدعم. إنه يعمل ويعيد أرقامًا معقولة:
\nselect t.channel,count(*),avg(satisfaction) from support_tickets t,customers c where t.customer_id=c.customer_id and closed_at is not null and opened_at>='2025-01-01' group by 1 order by 3 desc;على المراجع أن يجتهد ليجيب عن أسئلة أساسية. لماذا customers هنا؟ (إنه غير مستخدم؛ بقي من نسخة سابقة، وهو الآن JOIN على أحدهم أن يفكّر فيه.) هل هذا شرط ربط أم شرط تصفية؟ إلى أي جدول ينتمي satisfaction؟ ما العمود 3؟ هل ينقص شرط 2025 حدٌّ أعلى أم أن ذلك مقصود؟ وهذا التحليل نفسه مكتوبًا ليُفحص:
-- Support satisfaction by contact channel, tickets opened in 2025.\n-- grain: one row per channel. Only closed tickets: open ones can't be rated yet.\nSELECT\n t.channel,\n COUNT(*) AS closed_tickets,\n COUNT(t.satisfaction) AS rated,\n ROUND(AVG(t.satisfaction), 2) AS avg_satisfaction\nFROM support_tickets AS t\nWHERE t.closed_at IS NOT NULL\n AND t.opened_at >= '2025-01-01'\n AND t.opened_at < '2026-01-01'\nGROUP BY t.channel\nORDER BY avg_satisfaction DESC;التغييرات، مرتّبة حسب أهميتها:
\nJOIN ... ON، ولا تكتب أبدًا فاصلة مع شرط في WHERE. عندها يقع شرط الربط بجانب الجدول الذي ينتمي إليه.GROUP BY 1 تسهيل مختلَف عليه؛ أما الأسماء فتصمد أمام تعديلات قائمة SELECT.rated بجانب المتوسط، وهو درس معدل الاستجابة من القسم 1.الكلمات المفتاحية بأحرف كبيرة، والفواصل في بداية السطر أو نهايته، وعرض المسافات البادئة، كلها أعراف فريق. اختر واحدًا، وطبّقه في كل مكان، ودع أداة تنسيق تفرضه. الاتساق أهم بكثير من الأسلوب الذي يفوز.
\n\nSQL معيار، لكن لكل محرّك دواله الخاصة ودرجة تساهله الخاصة. كل ما في هذه الدورة في الغالب يعمل دون تغيير في PostgreSQL: الـ JOIN، والـ CTEs، والـ CTEs التكرارية، ودوال النافذة، وFILTER، وNULLIF، وCOALESCE، وIS DISTINCT FROM. وتتجمّع الفروق في مواضع قليلة:
| المهمة | \nSQLite | \nPostgreSQL | \n
|---|---|---|
| تسمية الشهر | \nstrftime('%Y-%m', d) | \nto_char(d, 'YYYY-MM') | \n
| بداية الشهر | \ndate(d, 'start of month') | \ndate_trunc('month', d) | \n
| إضافة فترة زمنية | \ndate(d, '+7 days') | \nd + INTERVAL '7 days' | \n
| الساعات بين لحظتين | \n(julianday(b) - julianday(a)) * 24 | \nEXTRACT(EPOCH FROM b - a) / 3600 | \n
| مطابقة غير حسّاسة لحالة الأحرف | \nLIKE (ASCII) | \nILIKE | \n
| الاختيار بين احتمالين | \nIIF(c, a, b) أو CASE | \nCASE | \n
| عدّ شرط | \nSUM(cond) أو FILTER | \nCOUNT(*) FILTER (WHERE cond) | \n
التغيير الأكبر يقع تحت الجدول. لدى PostgreSQL نوعا date وtimestamp حقيقيان، فتُقارَن أعمدة التاريخ كتواريخ، وتعيد العمليات الحسابية على التواريخ فترات زمنية (intervals) لا أرقامًا. والقيم المنطقية نوع حقيقي أيضًا: SUM(status = 'cancelled') يفشل هناك لأنك لا تستطيع جمع قيمة منطقية، ولهذا يكون FILTER هو الخيار القابل للنقل.
فرقان أصغر يوقعان الناس باستمرار. القسمة الصحيحة تقتطع الكسور في المحرّكين (7 / 2 تساوي 3)، فاستمر في كتابة 100.0 * للنسب المئوية. ويضع PostgreSQL قيم NULL أخيرًا في الترتيب التصاعدي بينما يضعها SQLite أولًا، فأضف NULLS FIRST أو NULLS LAST كلما كان موضع NULL مهمًا.
التمرين مهمة نقل حقيقية: query من مستودع البيانات يفشل في SQLite. بعد ذلك، يجمع المشروع الختامي الدورة كلها.
\n","toc":[{"id":"sec-1","text":"query على شخص آخر أن يفحصه","level":2},{"id":"sec-2","text":"من SQLite إلى PostgreSQL","level":2}],"takeaways":["الـ SQL المقروء يستخدم JOIN … ON صريحًا، وعمودًا واحدًا في كل سطر، وأسماء مستعارة حسب الأدوار، وخطوات CTE مسمّاة، وتعليقات تشرح لماذا لا ماذا.","احذف ما لا يستخدمه الـ query، مثل عمليات الربط غير المستخدمة وSELECT *، لأن كل جدول إضافي احتمال fan-out وسؤال على المراجع.","التعامل مع التواريخ هو أكبر فرق بين SQLite وPostgreSQL؛ فـ strftime وjulianday تصبحان date_trunc وto_char وفترات زمنية (intervals) وأنواع تاريخ حقيقية.","SQLite أكثر تساهلًا من PostgreSQL (الأعمدة المجرّدة، وLIKE غير الحسّاس لحالة الأحرف، والقيم المنطقية كـ 0/1)، فقد يفشل query يعمل في SQLite أو يتصرّف بشكل مختلف في PostgreSQL."],"further":[{"title":"SQLite quirks, caveats and gotchas","url":"https://www.sqlite.org/quirks.html"},{"title":"PostgreSQL date/time functions and operators","url":"https://www.postgresql.org/docs/current/functions-datetime.html"},{"title":"PostgreSQL pattern matching (LIKE and ILIKE)","url":"https://www.postgresql.org/docs/current/functions-matching.html"}],"quiz":[{"q":"تظهر العبارة FROM support_tickets t, customers c WHERE t.customer_id = c.customer_id في query لا يستخدم أي عمود من c. إطلاقًا. ماذا يجب أن يطلب المراجع؟
أي تعبير في SQLite له مقابل مباشر في PostgreSQL هو date_trunc('month', order_date)؟
julianday(order_date)","why":"تحوّل julianday التاريخ إلى رقم يوم؛ ولا تقتطعه إلى الشهر."},{"text":"strftime('%w', order_date)","why":"هذا رقم يوم الأسبوع، لا بداية الشهر."},{"text":"date(order_date, '+1 month')","why":"هذا يضيف شهرًا؛ ومقابله في PostgreSQL هو order_date + INTERVAL '1 month'."},{"text":"date(order_date, 'start of month')","why":"صحيح. كلاهما يعيد اليوم الأول من شهر الطلب. يعيد PostgreSQL قيمة timestamp، ويعيد SQLite نصًا بالصيغة ‘YYYY-MM-01’."}],"answer":3},{"q":"هذا يعمل في SQLite: SELECT channel, status, COUNT(*) FROM orders GROUP BY channel. ماذا يحدث في PostgreSQL؟
status ليس ضمن التجميع ولا داخل دالة تجميع.","why":"صحيح. يفرض PostgreSQL قاعدة GROUP BY التي يتساهل فيها SQLite، فيصبح خطأ العمود المجرّد خطأً لا يمكن أن يفوتك."},{"text":"يعيد النتيجة نفسها التي يعيدها SQLite.","why":"يرفض PostgreSQL اختيار قيمة اعتباطية لعمود مجرّد."},{"text":"يعيد صفًا لكل قناة وحالة.","why":"هذا يحتاج إلى GROUP BY channel, status؛ ولا يضيف PostgreSQL أعمدة التجميع نيابةً عنك."}],"answer":0},{"q":"يجد WHERE email LIKE '%@EXAMPLE.COM' كل العملاء الـ 600 في SQLite. كم عميلًا يجد في PostgreSQL، حيث تُخزَّن عناوين البريد بأحرف صغيرة؟
وجدت هدى هذا الـ query في مستودع البيانات على PostgreSQL وتريد الأرقام نفسها من قاعدة بيانات SQLite الخاصة بـ Cartwheel: للعملاء في دبي، صف واحد لكل شهر في 2025 فيه month (‘YYYY-MM’) وorders (الطلبات غير الملغاة) وapp_orders (الطلبات التي قُدّمت عبر تطبيق الجوال). رتّب حسب month. الترتيب مهم.
الكود المبدئي يفشل في SQLite. ترجم كل جزء خاص بـ PostgreSQL إلى SQLite وأبقِ المنطق كما هو.
\n","hints":["شغّله واقرأ أول خطأ. ثم ابحث عن كل ميزة خاصة بـ PostgreSQL: تحويلات::، وto_char، وdate_trunc، وILIKE، والقيم الحرفية DATE '...'.","تسمية الشهر بالصيغة ‘YYYY-MM’ في SQLite هي strftime('%Y-%m', o.order_date). التواريخ نصوص ISO، فتصبح القيم الحرفية للتاريخ نصوصًا عادية.","LIKE في SQLite لا يميّز حالة الأحرف الإنجليزية أصلًا، فيصبح ILIKE هو LIKE. أما COUNT(*) FILTER (WHERE ...) فيعمل في المحرّكين ويمكن أن يبقى."],"explanation":"أربعة أشياء خاصة بـ PostgreSQL: التحويل ::timestamp، وto_char مع date_trunc، وILIKE، والقيم الحرفية ذات النوع DATE '...'. في SQLite تسمية الشهر هي strftime('%Y-%m', ...)، ونص ISO لا يحتاج إلى تحويل، وLIKE يتجاهل حالة الأحرف الإنجليزية أصلًا. وFILTER جزء من SQL القياسي ويعمل دون تغيير. لاحظ الفخ المعاكس إن عاد هذا الـ query يومًا: LIKE 'MOBILE%' في SQLite يطابق ‘mobile_app’، لكن LIKE نفسه في PostgreSQL لن يطابق شيئًا، ولهذا استخدم الأصل ILIKE. كان ديسمبر أكثر أشهر دبي ازدحامًا، بـ 23 طلبًا.