الخطوة القادمة:
ماذا لو أردنا عرض العملاء
الذين لديهم أكثر من 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
# 🟢 Day 6 — (حل المشكلة الحقيقية: OrderDetails)
📌 Lesson 5: حل مشكلة المنتجات داخل الطلب (OrderDetails)
#Day6 #ERP_Project
---
🎯 المشكلة:
الطلب يحتوي على عدة منتجات ❗️
---
❌ لا يمكن تخزينها داخل Orders
---
💡 الحل الاحترافي:
إنشاء جدول جديد:
OrderDetails
---
🔥 الكود:
CREATE TABLE OrderDetails (
ID INT PRIMARY KEY IDENTITY,
OrderID INT,
ProductID INT,
Quantity INT,
FOREIGN KEY (OrderID) REFERENCES Orders(OrderID)
);
---
📊 ماذا حللنا؟
✔️ فصلنا الطلب عن التفاصيل
✔️ أصبح كل طلب يحتوي على عدة منتجات
✔️ حللنا مشكلة Many-to-Many
---
🎯 أصبح النظام كالتالي:
Orders → معلومات عامة
OrderDetails → تفاصيل المنتجات
---
🔥 Challenge:
ما نوع العلاقة بين:
Orders و OrderDetails ؟
💬 اكتب الإجابة
:::
📌 Lesson 5: حل مشكلة المنتجات داخل الطلب (OrderDetails)
#Day6 #ERP_Project
---
🎯 المشكلة:
الطلب يحتوي على عدة منتجات ❗️
---
❌ لا يمكن تخزينها داخل Orders
---
💡 الحل الاحترافي:
إنشاء جدول جديد:
OrderDetails
---
🔥 الكود:
CREATE TABLE OrderDetails (
ID INT PRIMARY KEY IDENTITY,
OrderID INT,
ProductID INT,
Quantity INT,
FOREIGN KEY (OrderID) REFERENCES Orders(OrderID)
);
---
📊 ماذا حللنا؟
✔️ فصلنا الطلب عن التفاصيل
✔️ أصبح كل طلب يحتوي على عدة منتجات
✔️ حللنا مشكلة Many-to-Many
---
🎯 أصبح النظام كالتالي:
Orders → معلومات عامة
OrderDetails → تفاصيل المنتجات
---
🔥 Challenge:
ما نوع العلاقة بين:
Orders و OrderDetails ؟
💬 اكتب الإجابة
:::
🔥 تحدي :
اكتب استعلام يعرض:
اسم العميل + تاريخ الطلب
💬 اكتب الحل في التعليقات
اكتب استعلام يعرض:
اسم العميل + تاريخ الطلب
💬 اكتب الحل في التعليقات
❤1
🎯 Lesson 7 — Foreign Keys
ليست مجرد سطر SQL... إنها حارس بيانات النظام
📌 Lesson 7 — هل يمكن إنشاء طلب لعميل غير موجود؟ 🤔
تخيل أنك تعمل على نظام مبيعات...
وأحد المبرمجين نفذ هذا الأمر:
لكن...
❗️العميل رقم 999 غير موجود أصلاً!
هل يجب أن يسمح النظام بهذا؟
لو سمح بذلك...
سيصبح لدينا طلب بدون صاحب!
وهنا تبدأ مشاكل التقارير والفواتير والأنظمة المالية.
💡 لهذا السبب نستخدم Foreign Key.
هو لا يربط الجداول فقط...
بل يحمي البيانات من الأخطاء.
🎯 بدون Foreign Key:
❌ Orders قد تشير إلى Customer غير موجود.
أما مع Foreign Key:
✅ النظام يمنع الخطأ قبل تخزين البيانات.
ليست مجرد سطر SQL... إنها حارس بيانات النظام
📌 Lesson 7 — هل يمكن إنشاء طلب لعميل غير موجود؟ 🤔
تخيل أنك تعمل على نظام مبيعات...
وأحد المبرمجين نفذ هذا الأمر:
INSERT INTO Orders(CustomerID)
VALUES(999);
لكن...
❗️العميل رقم 999 غير موجود أصلاً!
هل يجب أن يسمح النظام بهذا؟
لو سمح بذلك...
سيصبح لدينا طلب بدون صاحب!
وهنا تبدأ مشاكل التقارير والفواتير والأنظمة المالية.
💡 لهذا السبب نستخدم Foreign Key.
هو لا يربط الجداول فقط...
بل يحمي البيانات من الأخطاء.
🎯 بدون Foreign Key:
❌ Orders قد تشير إلى Customer غير موجود.
أما مع Foreign Key:
✅ النظام يمنع الخطأ قبل تخزين البيانات.
❤4
تخيل أن مدير الشركة طلب منك تقريرًا يحتوي على:
✅ رقم الطلب
✅ اسم العميل
✅ تاريخ الطلب
لكن...
اسم العميل موجود في جدول Customers.
ورقم الطلب موجود في Orders.
كيف نجمعهما؟
هنا يأتي دور INNER JOIN.
🎯 Challenge
قبل رؤية الكود...
توقع النتيجة.
هل سيظهر كل العملاء؟
أم فقط العملاء الذين لديهم طلبات؟
اكتب توقعك.
✅ رقم الطلب
✅ اسم العميل
✅ تاريخ الطلب
لكن...
اسم العميل موجود في جدول Customers.
ورقم الطلب موجود في Orders.
كيف نجمعهما؟
هنا يأتي دور INNER JOIN.
🎯 Challenge
قبل رؤية الكود...
توقع النتيجة.
هل سيظهر كل العملاء؟
أم فقط العملاء الذين لديهم طلبات؟
اكتب توقعك.
الكود
SELECT
O.OrderID,
C.CustomerName,
O.OrderDate
FROM Orders O
INNER JOIN Customers C
ON O.CustomerID = C.CustomerID;
SELECT
O.OrderID,
C.CustomerName,
O.OrderDate
FROM Orders O
INNER JOIN Customers C
ON O.CustomerID = C.CustomerID;