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.