Over-fetching Problem في SQL: الحل الأمثل 2026

Over-fetching Problem: لما تجيب كل حاجة وانت محتاج جزء بس 🍽️
البوست اللي فات كنا اتكلمنا عن سيناريو في الكافيه، وقلت للويتر تطلب حاجات كتير ومبهدلته 😅
هنعمل نفس السيناريو، بس وإنت جعان 😋

السيناريو: الكافيه وجبلك كل حاجة 😲​

قلت للويتر:
"أنا عايز ساندوتش برجر"

الويتر مشي وفجأة رجع بصينية ضخمة فيها كل الأكل اللي الكافيه بيقدمه! 😱

• إنت طلبت ساندوتش واحد
• لكن جابلك كل حاجة موجودة في المطبخ
• الترابيزة بقت مزحومة من غير داعي
• والنتيجة: أكل كتير مش محتاجه

وده بالظبط اللي بيحصل جوه database لما تكتب:

SELECT * FROM users;

---

فهم المشكلة في SQL 📊​

خلينا نقول عندنا جدول مستخدمين (users) فيه الأعمدة:

name, email, password, phone, address, bio, profile_picture, created_at, updated_at

المطلوب: نعرض بس اسم المستخدم والإيميل بتاعه

لو كتبت:

SELECT * FROM users;

يعني انت قلت للـ Database: "هاتلي كل حاجة!" 😅

• انت محتاج عمودين بس: name, email
• لكن الـ Database جابتلك كل الأعمدة:
  password, phone, address, bio, profile_picture, created_at, updated_at

لو عندك 1000 مستخدم وكل واحد فيه 15 عمود → 15,000 قيمة بتتنقل، وانت محتاج 2,000 قيمة بس!

---

المشكلة دي اسمها إيه؟ 🤔​

دي اسمها Over-fetching Problem أو SELECT * Anti-pattern

• معناها: بتجيب بيانات أكتر من اللي محتاجه فعليًا
• زي ما الويتر جابلك الصينية كلها وانت طلبت ساندوتش واحد فقط 🍔

---

الحل: حدد الأعمدة اللي محتاجها ✅​

بدل ما الويتر يجيب كل حاجة، قلتله بوضوح:
"أنا عايز ساندوتش برجر بس!"

وفي SQL معناه:

SELECT name, email FROM users;

النتيجة:

1. حجم البيانات المنقولة أقل 📉
2. السيرفر أسرع ⚡
3. استهلاك الـ Memory أقل 💾
4. الشبكة مش محملة بيانات زيادة 🌐

نصيحة: لما تستخدم *، استخدمها بس لما الجدول خفيف وانت فعلا محتاج كل البيانات.

---

الخلاصة: مشاكل الأداء في الـ Database 🛠️​

• المشكلة الأولى: N+1 Problem (الويتر اللي رايح جاي)
• المشكلة الثانية: Over-fetching Problem (الصينية المليانة) 🍽️

باتباعك للطريقة الصحيحة وتحديد الأعمدة اللي محتاجها، هتوفر وقت، موارد، وأداء أفضل للـ database.