لو بتكتب كل تقرير تحليلي بـ subquery طويل وself-join عشان تجيب ترتيب موظف داخل قسمه أو مجموع تراكمي يومي، الـ window functions بتوفر 80% من الكود ده وبتدّي performance أحسن بكتير. المقال بيديك كود شغّال على PostgreSQL بأرقام حقيقية.
SQL Window Functions: ranking و running total بدون subqueries
المشكلة باختصار
الـ GROUP BY بيعمل حاجة واحدة: بياخد الصفوف في المجموعة ويرجّعها كصف واحد مجمّع. لو عايز تحتفظ بتفاصيل كل صف، وفي نفس الوقت تضيف قيمة محسوبة على المجموعة (زي ترتيب الموظف داخل قسمه، أو total مبيعاته تراكمي)، الـ GROUP BY لوحده مش كفاية. الـ Window Function بتشتغل على "نافذة" من الصفوف حوالين كل صف من غير ما تجمّعهم.
مثال واقعي: ranking المبيعات داخل كل قسم
عندك جدول sales فيه حوالي 500 ألف صف، كل صف فيه employee_id, department, sale_amount. عايز تعرف ترتيب كل موظف داخل قسمه لسنة 2025.
SELECT
employee_id,
department,
sale_amount,
RANK() OVER (
PARTITION BY department
ORDER BY sale_amount DESC
) AS dept_rank
FROM sales
WHERE year = 2025;في الطريقة التقليدية، هتحتاج self-join على نفس الجدول وتعد كم صف أكبر من الصف الحالي داخل نفس القسم. التكلفة: O(n²) تقريبًا. الـ window function: O(n log n) لأنها SORT واحدة لكل partition.
قياس حقيقي
على جدول 500K صف، PostgreSQL 15، جهاز 8 CPU / 16GB RAM:
- Self-join approach: حوالي 4.2 ثانية.
- Window function: حوالي 280 ملي ثانية.
تقريبًا 15 ضعف أسرع، والكود بقى 4 أسطر بدل 15. الفارق ده بيكبر أكتر كل ما الجدول يكبر.
running total - مهم جدًا في dashboards
لو عندك dashboard بيعرض مبيعات كل يوم مع المجموع التراكمي من أول السنة:
SELECT
sale_date,
daily_total,
SUM(daily_total) OVER (
ORDER BY sale_date
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
) AS running_total
FROM daily_sales
ORDER BY sale_date;الـ ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW معناها: جمّع كل الصفوف من بداية النافذة لحد الصف ده. لو عايز running total لكل شهر لوحده، ضيف PARTITION BY DATE_TRUNC('month', sale_date) وخلاص.
