تطبيق عملي واضح
لدينا جدول orders
وجدول customers
SELECT customers.name, orders.total
FROM orders
JOIN customers
ON orders.customer_id = customers.id;
ما الذي حدث هنا؟
- ربطنا الطلب بالعميل
- جمعنا بيانات من مصدرين
- أعدنا تكوين المعلومة
لدينا جدول orders
وجدول customers
SELECT customers.name, orders.total
FROM orders
JOIN customers
ON orders.customer_id = customers.id;
ما الذي حدث هنا؟
- ربطنا الطلب بالعميل
- جمعنا بيانات من مصدرين
- أعدنا تكوين المعلومة
خطأ شائع في JOIN
نسيان شرط الربط الصحيح.
إذا كان ON غير صحيح،
ستحصل على نتائج مضاعفة أو خاطئة.
JOIN ليس خطيراً،
لكن استخدامه بدون فهم خطير.
نسيان شرط الربط الصحيح.
إذا كان ON غير صحيح،
ستحصل على نتائج مضاعفة أو خاطئة.
JOIN ليس خطيراً،
لكن استخدامه بدون فهم خطير.
📝 تمرين:
لديك جدول products
وجدول order_items
اكتب استعلاماً يعرض:
اسم المنتج + الكمية المباعة.
لديك جدول products
وجدول order_items
اكتب استعلاماً يعرض:
اسم المنتج + الكمية المباعة.
بيكون الشرح عبر مراحل المرحلة التالية هي
من عرض البيانات إلى تحليلها (GROUP BY & HAVING)
من عرض البيانات إلى تحليلها (GROUP BY & HAVING)
📘 الدرس: لماذا نستخدم GROUP BY؟
حتى الآن، كنا نعرض بيانات.
لكن في الواقع،
نحن لا نريد البيانات نفسها…
نريد: تحليلها.
مثال:بدلاً من:عرض كل الطلبات
نريد:كم عدد الطلبات لكل عميل؟
أو: إجمالي المبيعات لكل مدينة؟
هنا يأتي دور GROUP BY
GROUP BY تعني:
تجميع البيانات حسب معيار معين
ثم تطبيق عملية عليها (مثل COUNT أو SUM)
مثال بسيط:
كم عدد الطلبات لكل عميل؟
❓ السؤال لك: هل ترى الفرق بين "عرض البيانات"
و "تحليل البيانات"؟
حتى الآن، كنا نعرض بيانات.
لكن في الواقع،
نحن لا نريد البيانات نفسها…
نريد: تحليلها.
مثال:بدلاً من:عرض كل الطلبات
نريد:كم عدد الطلبات لكل عميل؟
أو: إجمالي المبيعات لكل مدينة؟
هنا يأتي دور GROUP BY
GROUP BY تعني:
تجميع البيانات حسب معيار معين
ثم تطبيق عملية عليها (مثل COUNT أو SUM)
مثال بسيط:
كم عدد الطلبات لكل عميل؟
❓ السؤال لك: هل ترى الفرق بين "عرض البيانات"
و "تحليل البيانات"؟
👍1
📘 اليوم التطبيق العملي
📘 التطبيق العملي على GROUP BY
لدينا جدول orders:
order_id | customer_id | total
نريد:
عدد الطلبات لكل عميل
SELECT customer_id, COUNT(*) AS total_orders
FROM orders
GROUP BY customer_id;
ما الذي حدث؟
1- جمعنا البيانات حسب customer_id
2- حسبنا عدد الطلبات لكل مجموعة
النتيجة:
كل عميل + عدد طلباته
مثال آخر:
إجمالي المبيعات لكل عميل:
SELECT customer_id, SUM(total) AS total_sales
FROM orders
GROUP BY customer_id;
الآن بدأنا نحلل البيانات فعلاً.
❓ أيهما أهم برأيك:
COUNT أم SUM في عملك؟
📘 التطبيق العملي على GROUP BY
لدينا جدول orders:
order_id | customer_id | total
نريد:
عدد الطلبات لكل عميل
SELECT customer_id, COUNT(*) AS total_orders
FROM orders
GROUP BY customer_id;
ما الذي حدث؟
1- جمعنا البيانات حسب customer_id
2- حسبنا عدد الطلبات لكل مجموعة
النتيجة:
كل عميل + عدد طلباته
مثال آخر:
إجمالي المبيعات لكل عميل:
SELECT customer_id, SUM(total) AS total_sales
FROM orders
GROUP BY customer_id;
الآن بدأنا نحلل البيانات فعلاً.
❓ أيهما أهم برأيك:
COUNT أم SUM في عملك؟
👍1
📝 اليوم — تمرين
📝 تمرين اليوم:
لدينا جدول orders يحتوي على:
order_id, customer_id, total
المطلوب:
1- حساب عدد الطلبات لكل عميل
2- حساب إجمالي المبيعات لكل عميل
حاول كتابة الاستعلام بنفسك قبل رؤية الحل.
لا تستعجل… التفكير أهم من الحل.
📝 تمرين اليوم:
لدينا جدول orders يحتوي على:
order_id, customer_id, total
المطلوب:
1- حساب عدد الطلبات لكل عميل
2- حساب إجمالي المبيعات لكل عميل
حاول كتابة الاستعلام بنفسك قبل رؤية الحل.
لا تستعجل… التفكير أهم من الحل.
👍2
📘 اليوم — الحل + التحليل الاحترافي
📘 حل التمرين
الحل الأول:
SELECT customer_id, COUNT(*) AS total_orders
FROM orders
GROUP BY customer_id;
الحل الثاني:
SELECT customer_id, SUM(total) AS total_sales
FROM orders
GROUP BY customer_id;
---
التحليل:
لماذا استخدمنا GROUP BY؟
لأننا لا نريد كل الطلبات،
بل نريد نتيجة مجمعة لكل عميل.
الخطأ الشائع:
كتابة COUNT بدون GROUP BY
وهذا يعطي نتيجة واحدة فقط.
---
معلومة مهمة:
GROUP BY بدون فهم
يعطي نتائج مضللة.
📘 حل التمرين
الحل الأول:
SELECT customer_id, COUNT(*) AS total_orders
FROM orders
GROUP BY customer_id;
الحل الثاني:
SELECT customer_id, SUM(total) AS total_sales
FROM orders
GROUP BY customer_id;
---
التحليل:
لماذا استخدمنا GROUP BY؟
لأننا لا نريد كل الطلبات،
بل نريد نتيجة مجمعة لكل عميل.
الخطأ الشائع:
كتابة COUNT بدون GROUP BY
وهذا يعطي نتيجة واحدة فقط.
---
معلومة مهمة:
GROUP BY بدون فهم
يعطي نتائج مضللة.
الخطوة القادمة:
ماذا لو أردنا عرض العملاء
الذين لديهم أكثر من 5 طلبات فقط؟
هنا نحتاج مفهوم جديد:
HAVING
سنبدأ به في الدرس القادم.
ماذا لو أردنا عرض العملاء
الذين لديهم أكثر من 5 طلبات فقط؟
هنا نحتاج مفهوم جديد:
HAVING
سنبدأ به في الدرس القادم.
تحديث مهم بخصوص خطة القناة
خلال الفترة القادمة سيتم إيقاف السلسلة الحالية مؤقتًا، والانتقال إلى مسار جديد أكثر احترافية وتركيزًا على قواعد بيانات وأنظمة ERP العملية.
الهدف من هذه الخطوة هو تقديم محتوى أقرب لبيئة العمل الحقيقية، يساعد على فهم تصميم الأنظمة الإدارية وتحليل قواعد البيانات بشكل عملي واحترافي.
بإذن الله ستكون المرحلة القادمة أقوى وأكثر فائدة لكل المهتمين بمجال قواعد البيانات وتطوير الأنظمة 🚀
خلال الفترة القادمة سيتم إيقاف السلسلة الحالية مؤقتًا، والانتقال إلى مسار جديد أكثر احترافية وتركيزًا على قواعد بيانات وأنظمة ERP العملية.
الهدف من هذه الخطوة هو تقديم محتوى أقرب لبيئة العمل الحقيقية، يساعد على فهم تصميم الأنظمة الإدارية وتحليل قواعد البيانات بشكل عملي واحترافي.
بإذن الله ستكون المرحلة القادمة أقوى وأكثر فائدة لكل المهتمين بمجال قواعد البيانات وتطوير الأنظمة 🚀
هذه الخطة مبنية على 3 مبادئ:
كل درس = جزء من مشروع
كل يوم = مخرجات ملموسة
كل 3 أيام = تفاعل + Challenge
كل درس = جزء من مشروع
كل يوم = مخرجات ملموسة
كل 3 أيام = تفاعل + Challenge
🚀 بداية مشروع احترافي على القناة
إذا كنت تعرف أساسيات SQL لكن لا تعرف كيف تبني نظام حقيقي…
فهذا هو التحول الذي كنت تنتظره 👇
🔥 ابتداءً من اليوم:
سنبني معًا نظام ERP متكامل باستخدام SQL Server
❌ لا يوجد شرح عشوائي
❌ لا يوجد نظريات بدون تطبيق
بل:
✅ مشروع حقيقي خطوة بخطوة
✅ من مستوى متوسط → احتراف
✅ كل درس = جزء من النظام
---
🎯 ماذا سنبني؟
نظام يحتوي على:
- إدارة العملاء (Customers)
- المنتجات (Products)
- الطلبات (Orders)
- المخزون (Inventory)
- الموظفين (HR)
---
💡 الهدف النهائي:
تحويلك من:
"شخص يعرف SQL"
إلى:
"شخص يبني أنظمة حقيقية"
---
📅 الخطة:
30 يوم = نظام كامل + مهارات احترافية
---
🔥 إذا أنت جاد: ابد اليوم
إذا كنت تعرف أساسيات SQL لكن لا تعرف كيف تبني نظام حقيقي…
فهذا هو التحول الذي كنت تنتظره 👇
🔥 ابتداءً من اليوم:
سنبني معًا نظام ERP متكامل باستخدام SQL Server
❌ لا يوجد شرح عشوائي
❌ لا يوجد نظريات بدون تطبيق
بل:
✅ مشروع حقيقي خطوة بخطوة
✅ من مستوى متوسط → احتراف
✅ كل درس = جزء من النظام
---
🎯 ماذا سنبني؟
نظام يحتوي على:
- إدارة العملاء (Customers)
- المنتجات (Products)
- الطلبات (Orders)
- المخزون (Inventory)
- الموظفين (HR)
---
💡 الهدف النهائي:
تحويلك من:
"شخص يعرف SQL"
إلى:
"شخص يبني أنظمة حقيقية"
---
📅 الخطة:
30 يوم = نظام كامل + مهارات احترافية
---
🔥 إذا أنت جاد: ابد اليوم
👍3
📌 Lesson 1: كيف يفكر نظام ERP؟
#Day1 #ERP_Project
قبل كتابة كود، افهم عمل النظام:
🛒 السيناريو:
1️⃣ اختيار المنتج
2️⃣ إنشاء طلب (Order)
3️⃣ إضافة التفاصيل
4️⃣ خصم الكمية من المخزون
5️⃣ تسجيل العملية
💡 هذا يسمى: Business Flow (تدفق العمل)
🎯 مهمتك كمطور:
ليس فقط SQL ❌ بل تحويل السيناريو إلى: جداول + علاقات + منطق
📊 العناصر الأساسية:
- Customers
- Products
- Orders
- Inventory
🔥 Challenge:
هل العميل يمكن أن يملك أكثر من طلب؟ ولماذا؟
💬 اكتب إجابتك في التعليقات
#Day1 #ERP_Project
قبل كتابة كود، افهم عمل النظام:
🛒 السيناريو:
1️⃣ اختيار المنتج
2️⃣ إنشاء طلب (Order)
3️⃣ إضافة التفاصيل
4️⃣ خصم الكمية من المخزون
5️⃣ تسجيل العملية
💡 هذا يسمى: Business Flow (تدفق العمل)
🎯 مهمتك كمطور:
ليس فقط SQL ❌ بل تحويل السيناريو إلى: جداول + علاقات + منطق
📊 العناصر الأساسية:
- Customers
- Products
- Orders
- Inventory
🔥 Challenge:
هل العميل يمكن أن يملك أكثر من طلب؟ ولماذا؟
💬 اكتب إجابتك في التعليقات
🧠 سؤال سريع (مهم جدًا)
في نظام ERP:
ما نوع العلاقة بين:
Customers و Orders ؟
---
A) One-to-One
B) One-to-Many
C) Many-to-Many
---
💬 اكتب الإجابة + السبب
🎯 الهدف:
نبدأ نفكر كمحللين أنظمة وليس فقط مبرمجين
🔥 سيتم شرح الإجابة في الدرس القادم
في نظام ERP:
ما نوع العلاقة بين:
Customers و Orders ؟
---
A) One-to-One
B) One-to-Many
C) Many-to-Many
---
💬 اكتب الإجابة + السبب
🎯 الهدف:
نبدأ نفكر كمحللين أنظمة وليس فقط مبرمجين
🔥 سيتم شرح الإجابة في الدرس القادم
🟠 🧠 (Relationships + أول كود)
📌 Lesson 2: فهم العلاقات (Relationships)
#Day3 #ERP_Project
---
📊 الإجابة الصحيحة:
Customers → Orders = One-to-Many ✅
---
💡 لماذا؟
لأن:
عميل واحد يمكن أن ينشئ عدة طلبات
لكن كل طلب يعود لعميل واحد فقط
---
🔥 هذا أهم مفهوم في قواعد البيانات:
Relationship Design
---
🎯 الآن نبدأ أول خطوة حقيقية:
إنشاء جدول Customers 👇
📌 Lesson 2: فهم العلاقات (Relationships)
#Day3 #ERP_Project
---
📊 الإجابة الصحيحة:
Customers → Orders = One-to-Many ✅
---
💡 لماذا؟
لأن:
عميل واحد يمكن أن ينشئ عدة طلبات
لكن كل طلب يعود لعميل واحد فقط
---
🔥 هذا أهم مفهوم في قواعد البيانات:
Relationship Design
---
🎯 الآن نبدأ أول خطوة حقيقية:
إنشاء جدول Customers 👇
CREATE TABLE Customers (
CustomerID INT PRIMARY KEY IDENTITY,
Name NVARCHAR(100) NOT NULL
);
CustomerID INT PRIMARY KEY IDENTITY,
Name NVARCHAR(100) NOT NULL
);
🎯 ماذا تعلمنا؟
- كل جدول يمثل كيان (Entity)
- كل علاقة تمثل ارتباط منطقي
🔥 Challenge:
كيف تتوقع شكل جدول Orders؟
فكر في:
- ما هي الأعمدة؟
- كيف نربطه بـ Customers؟
💬 اكتب تصميمك في التعليقات
- كل جدول يمثل كيان (Entity)
- كل علاقة تمثل ارتباط منطقي
🔥 Challenge:
كيف تتوقع شكل جدول Orders؟
فكر في:
- ما هي الأعمدة؟
- كيف نربطه بـ Customers؟
💬 اكتب تصميمك في التعليقات
📌 Lesson 3: كيف نفكر في تصميم Orders؟
#Day4 #ERP_Project
🎯 قبل ما نكتب أي كود…
لازم نسأل:
ما هو "Order" داخل النظام؟
---
🧠 تخيل هذا السيناريو:
عميل دخل واشترى منتجات 👇
النظام لازم يسجل:
* من هو العميل؟
* متى تم الطلب؟
* ما هو رقم الطلب؟
---
💡 إذًا جدول Orders يجب أن يحتوي على:
✔️ OrderID
✔️ CustomerID
✔️ OrderDate
---
❗️ سؤال مهم:
هل نضع المنتجات داخل Orders؟ 🤔
---
🚫 الجواب: لا
ليش؟
لأن:
الطلب الواحد يحتوي على أكثر من منتج
---
🔥 Challenge:
برأيك:
ما هو الحل الصحيح لتخزين المنتجات؟
💬 اكتب فكرتك
#Day4 #ERP_Project
🎯 قبل ما نكتب أي كود…
لازم نسأل:
ما هو "Order" داخل النظام؟
---
🧠 تخيل هذا السيناريو:
عميل دخل واشترى منتجات 👇
النظام لازم يسجل:
* من هو العميل؟
* متى تم الطلب؟
* ما هو رقم الطلب؟
---
💡 إذًا جدول Orders يجب أن يحتوي على:
✔️ OrderID
✔️ CustomerID
✔️ OrderDate
---
❗️ سؤال مهم:
هل نضع المنتجات داخل Orders؟ 🤔
---
🚫 الجواب: لا
ليش؟
لأن:
الطلب الواحد يحتوي على أكثر من منتج
---
🔥 Challenge:
برأيك:
ما هو الحل الصحيح لتخزين المنتجات؟
💬 اكتب فكرتك
❤1
# 🟢 Day 4 — (فهم Orders قبل الكود)
هذا المنشور هدفه “ترتيب التفكير” وليس كتابة كود
:::writing{variant="social_post" id="58213"}
📌 Lesson 3: كيف نفكر في تصميم Orders؟
#Day4 #ERP_Project
---
🎯 قبل ما نكتب أي كود…
لازم نسأل:
ما هو "Order" داخل النظام؟
---
🧠 تخيل هذا السيناريو:
عميل دخل واشترى منتجات 👇
النظام لازم يسجل:
- من هو العميل؟
- متى تم الطلب؟
- ما هو رقم الطلب؟
---
💡 إذًا جدول Orders يجب أن يحتوي على:
✔️ OrderID
✔️ CustomerID
✔️ OrderDate
---
❗️ سؤال مهم:
هل نضع المنتجات داخل Orders؟ 🤔
---
🚫 الجواب: لا
ليش؟
لأن:
الطلب الواحد يحتوي على أكثر من منتج
---
🔥 Challenge:
برأيك:
ما هو الحل الصحيح لتخزين المنتجات؟
💬 اكتب فكرتك
هذا المنشور هدفه “ترتيب التفكير” وليس كتابة كود
:::writing{variant="social_post" id="58213"}
📌 Lesson 3: كيف نفكر في تصميم Orders؟
#Day4 #ERP_Project
---
🎯 قبل ما نكتب أي كود…
لازم نسأل:
ما هو "Order" داخل النظام؟
---
🧠 تخيل هذا السيناريو:
عميل دخل واشترى منتجات 👇
النظام لازم يسجل:
- من هو العميل؟
- متى تم الطلب؟
- ما هو رقم الطلب؟
---
💡 إذًا جدول Orders يجب أن يحتوي على:
✔️ OrderID
✔️ CustomerID
✔️ OrderDate
---
❗️ سؤال مهم:
هل نضع المنتجات داخل Orders؟ 🤔
---
🚫 الجواب: لا
ليش؟
لأن:
الطلب الواحد يحتوي على أكثر من منتج
---
🔥 Challenge:
برأيك:
ما هو الحل الصحيح لتخزين المنتجات؟
💬 اكتب فكرتك
# 🟢 Day 5 — (إنشاء Orders Table + أول ربط حقيقي)
📌 Lesson 4: إنشاء جدول Orders وربطه بـ Customers
#Day5 #ERP_Project
---
🎯 الآن نحول التفكير إلى كود 👇
---
🔥 الكود:
CREATE TABLE Orders (
OrderID INT PRIMARY KEY IDENTITY,
CustomerID INT,
OrderDate DATETIME DEFAULT GETDATE(),
FOREIGN KEY (CustomerID) REFERENCES Customers(CustomerID)
);
---
💡 ماذا فعلنا هنا؟
✔️ أنشأنا جدول Orders
✔️ ربطناه بجدول Customers
✔️ كل طلب أصبح مرتبط بعميل
---
📊 هذا يسمى:
Relationship (ربط بين الجداول)
---
❗️ سيناريو مهم:
إذا حذفنا Customer مرتبط بطلب…
ماذا سيحدث؟ 🤔
---
🔥 Challenge:
جاوب:
هل يسمح النظام بالحذف أم يمنعه؟ ولماذا؟
💬 اكتب إجابتك
📌 Lesson 4: إنشاء جدول Orders وربطه بـ Customers
#Day5 #ERP_Project
---
🎯 الآن نحول التفكير إلى كود 👇
---
🔥 الكود:
CREATE TABLE Orders (
OrderID INT PRIMARY KEY IDENTITY,
CustomerID INT,
OrderDate DATETIME DEFAULT GETDATE(),
FOREIGN KEY (CustomerID) REFERENCES Customers(CustomerID)
);
---
💡 ماذا فعلنا هنا؟
✔️ أنشأنا جدول Orders
✔️ ربطناه بجدول Customers
✔️ كل طلب أصبح مرتبط بعميل
---
📊 هذا يسمى:
Relationship (ربط بين الجداول)
---
❗️ سيناريو مهم:
إذا حذفنا Customer مرتبط بطلب…
ماذا سيحدث؟ 🤔
---
🔥 Challenge:
جاوب:
هل يسمح النظام بالحذف أم يمنعه؟ ولماذا؟
💬 اكتب إجابتك
❤1