أهلاً بك 👋
هذه القناة مخصصة لتعلم قواعد بيانات SQL من الصفر
سنقدم:
🔹 دروس مبسطة
🔹 أمثلة عملي
🔹 تمارين واختبارات
📅 النشر سيكون منتظماً (3–4 مرات أسبوعياً)
✍️ شارك بالإجابة والتعليق… فالتفاعل هو طريق التعلم 🚀
هذه القناة مخصصة لتعلم قواعد بيانات SQL من الصفر
سنقدم:
🔹 دروس مبسطة
🔹 أمثلة عملي
🔹 تمارين واختبارات
📅 النشر سيكون منتظماً (3–4 مرات أسبوعياً)
✍️ شارك بالإجابة والتعليق… فالتفاعل هو طريق التعلم 🚀
❤8
أهلاً بك 👋
هذه القناة متخصصة في شرح قواعد بيانات SQL
من الصفر حتى المستوى الاحترافي
خطه هذ الشهر
✔️ شرح مبسط
✔️ أمثلة عملية
✔️ تمارين وتطبيقات
📌 النشر سيكون منتظماً
❓ لكي نبد بتطبيق الخطة السابقة اكتب مستواك الحالي :
مبتدئ / متوسط / متقدم
هذه القناة متخصصة في شرح قواعد بيانات SQL
من الصفر حتى المستوى الاحترافي
خطه هذ الشهر
✔️ شرح مبسط
✔️ أمثلة عملية
✔️ تمارين وتطبيقات
📌 النشر سيكون منتظماً
❓ لكي نبد بتطبيق الخطة السابقة اكتب مستواك الحالي :
مبتدئ / متوسط / متقدم
👍2❤1
📘 SQL من الصفر (1)
SQL هي لغة تُستخدم للتعامل مع قواعد البيانات
من خلالها يمكن:
- جلب البيانات
- إضافة بيانات
- تعديل وحذف البيانات
SQL هي لغة تُستخدم للتعامل مع قواعد البيانات
من خلالها يمكن:
- جلب البيانات
- إضافة بيانات
- تعديل وحذف البيانات
❤2
❌ خطأ شائع في قواعد البيانات
الخطأ:
الاعتقاد أن SQL هي قاعدة بيانات
✔️ الصحيح:
SQL لغة تُستخدم للتعامل مع قواعد البيانات
👀 هل كنت تعتقد ذلك سابقاً؟
الخطأ:
الاعتقاد أن SQL هي قاعدة بيانات
✔️ الصحيح:
SQL لغة تُستخدم للتعامل مع قواعد البيانات
👀 هل كنت تعتقد ذلك سابقاً؟
❤1
سؤال بسيط:
هل كل استعلام صحيح هو استعلام جيد؟
في الواقع،
كثير من الأكواد الصحيحة
هي سبب مشاكل كبيرة لاحقاً.
هل كل استعلام صحيح هو استعلام جيد؟
في الواقع،
كثير من الأكواد الصحيحة
هي سبب مشاكل كبيرة لاحقاً.
المبرمج يكتب استعلام SQL صحيح 100%
من ناحية الصياغة والقواعد.
لكن رغم ذلك:
يكون بطيئاً
يستهلك موارد كثيرة
يسبب ضغطاً على النظام
هنا يظن أغلب الناس أن الحل هو:
❌ تحسين الكود
❌ إضافة Index
❌ إعادة كتابة الاستعلام
بينما المشكلة الحقيقية أعمق:
السؤال نفسه الذي بُني عليه الاستعلام كان خطأ من البداية.
من ناحية الصياغة والقواعد.
لكن رغم ذلك:
يكون بطيئاً
يستهلك موارد كثيرة
يسبب ضغطاً على النظام
هنا يظن أغلب الناس أن الحل هو:
❌ تحسين الكود
❌ إضافة Index
❌ إعادة كتابة الاستعلام
بينما المشكلة الحقيقية أعمق:
السؤال نفسه الذي بُني عليه الاستعلام كان خطأ من البداية.
مثال عملي يوضح الفكرة
السيناريو
لنفترض أن لدينا نظام متجر إلكتروني
وفيه جدول اسمه:
orders
يحتوي على ملايين السجلات.
جاء طلب من الإدارة:
“نريد تقريراً يعرض كل الطلبات منذ بداية النظام”
المبرمج كتب الاستعلام التالي:
SELECT *
FROM orders;
الاستعلام:
✔ صحيح
✔ يعمل
✔ يعيد بيانات فعلاً
لكن النتيجة:
يستغرق 40 ثانية
يجمّد النظام
يستهلك الذاكرة
يسبب بطئاً لكل المستخدمين
السيناريو
لنفترض أن لدينا نظام متجر إلكتروني
وفيه جدول اسمه:
orders
يحتوي على ملايين السجلات.
جاء طلب من الإدارة:
“نريد تقريراً يعرض كل الطلبات منذ بداية النظام”
المبرمج كتب الاستعلام التالي:
SELECT *
FROM orders;
الاستعلام:
✔ صحيح
✔ يعمل
✔ يعيد بيانات فعلاً
لكن النتيجة:
يستغرق 40 ثانية
يجمّد النظام
يستهلك الذاكرة
يسبب بطئاً لكل المستخدمين
📌 مثال عملي على فكرة مهمة:
البطء في النظام
لا يعني دائماً أن المشكلة في الاستعلام نفسه.
أحياناً المشكلة تكون في السؤال
الذي طُرح قبل كتابة الاستعلام.
---
تخيّل هذا السيناريو:
لدينا جدول orders
يحتوي ملايين السجلات.
جاء طلب من الإدارة:
"نريد تقريراً يعرض كل الطلبات منذ بداية النظام"
فكتب المبرمج:
SELECT *
FROM orders;
الاستعلام صحيح 100%
ويعمل بدون أي خطأ.
لكن النتيجة:
- استعلام بطيء
- يستهلك الذاكرة
- يسبب ضغطاً على النظام
---
هنا يبدأ التفكير التقليدي:
🔹 نضيف Index
🔹 نعدّل الكود
🔹 نبحث عن طريقة لتسريعه
بينما المشكلة الحقيقية لم تكن في SQL أصلاً!
---
المشكلة كانت في السؤال نفسه:
من قال أننا نحتاج كل الطلبات منذ بداية النظام؟
السؤال الصحيح غالباً يكون:
"نريد تقريراً لطلبات آخر 3 أشهر فقط"
وعندها يصبح الاستعلام:
SELECT order_id, customer_id, total
FROM orders
WHERE order_date >= '2024-11-01';
النتيجة؟
✔ أسرع بكثير
✔ أخف على النظام
✔ يحقق الهدف الحقيقي
---
الخلاصة:
استعلام صحيح تقنياً
قد يكون سيئاً عملياً
إذا كان مبنياً على سؤال خاطئ.
المحترف لا يبدأ بالكود،
بل يبدأ بفهم السؤال أولاً.
---
السؤال لك:
❓ كم مرة كتبت استعلاماً معقداً
ثم اكتشفت أن المشكلة كانت في المطلوب نفسه؟
البطء في النظام
لا يعني دائماً أن المشكلة في الاستعلام نفسه.
أحياناً المشكلة تكون في السؤال
الذي طُرح قبل كتابة الاستعلام.
---
تخيّل هذا السيناريو:
لدينا جدول orders
يحتوي ملايين السجلات.
جاء طلب من الإدارة:
"نريد تقريراً يعرض كل الطلبات منذ بداية النظام"
فكتب المبرمج:
SELECT *
FROM orders;
الاستعلام صحيح 100%
ويعمل بدون أي خطأ.
لكن النتيجة:
- استعلام بطيء
- يستهلك الذاكرة
- يسبب ضغطاً على النظام
---
هنا يبدأ التفكير التقليدي:
🔹 نضيف Index
🔹 نعدّل الكود
🔹 نبحث عن طريقة لتسريعه
بينما المشكلة الحقيقية لم تكن في SQL أصلاً!
---
المشكلة كانت في السؤال نفسه:
من قال أننا نحتاج كل الطلبات منذ بداية النظام؟
السؤال الصحيح غالباً يكون:
"نريد تقريراً لطلبات آخر 3 أشهر فقط"
وعندها يصبح الاستعلام:
SELECT order_id, customer_id, total
FROM orders
WHERE order_date >= '2024-11-01';
النتيجة؟
✔ أسرع بكثير
✔ أخف على النظام
✔ يحقق الهدف الحقيقي
---
الخلاصة:
استعلام صحيح تقنياً
قد يكون سيئاً عملياً
إذا كان مبنياً على سؤال خاطئ.
المحترف لا يبدأ بالكود،
بل يبدأ بفهم السؤال أولاً.
---
السؤال لك:
❓ كم مرة كتبت استعلاماً معقداً
ثم اكتشفت أن المشكلة كانت في المطلوب نفسه؟
❤1
📘 الدرس الأول
قبل أن تتعلم SQL…
تعلّم شيئاً أهم:
كيف تفكّر في البيانات.
أغلب المبتدئين يتعلمون الأوامر:
SELECT
WHERE
JOIN
لكن القليل فقط يتعلم:
متى ولماذا يستخدمها.
هذه القناة لن تعطيك أوامر فقط،
بل ستعلّمك طريقة تفكير.
سؤال اليوم:
❓ عندما يُطلب منك تقرير، ما أول خطوة تفعلها؟
قبل أن تتعلم SQL…
تعلّم شيئاً أهم:
كيف تفكّر في البيانات.
أغلب المبتدئين يتعلمون الأوامر:
SELECT
WHERE
JOIN
لكن القليل فقط يتعلم:
متى ولماذا يستخدمها.
هذه القناة لن تعطيك أوامر فقط،
بل ستعلّمك طريقة تفكير.
سؤال اليوم:
❓ عندما يُطلب منك تقرير، ما أول خطوة تفعلها؟
📘 الدرس الثاني
ما الفرق بين:
البيانات – Data
والمعلومات – Information ؟
البيانات:
أرقام وجداول وسجلات خام.
المعلومات:
معنى مفيد مستخرج من البيانات.
وظيفة SQL ليست إظهار البيانات،
بل تحويلها إلى معلومات مفيدة.
تذكّر:
ليس كل استعلام يعرض بيانات
يعطي معلومات حقيقية.
سؤال:
❓ هل تكتب SQL لعرض البيانات أم لفهمها؟
ما الفرق بين:
البيانات – Data
والمعلومات – Information ؟
البيانات:
أرقام وجداول وسجلات خام.
المعلومات:
معنى مفيد مستخرج من البيانات.
وظيفة SQL ليست إظهار البيانات،
بل تحويلها إلى معلومات مفيدة.
تذكّر:
ليس كل استعلام يعرض بيانات
يعطي معلومات حقيقية.
سؤال:
❓ هل تكتب SQL لعرض البيانات أم لفهمها؟
📘 الدرس الثالث
قاعدة مهمة:
كل استعلام SQL
هو ترجمة لسؤال بشري.
إذا كان السؤال ضعيفاً،
فالاستعلام سيكون ضعيفاً.
المشكلة غالباً لا تبدأ في الكود،
بل في فهم المطلوب.
قبل أن تكتب:
SELECT
اسأل:
ماذا أريد فعلاً؟
سؤال اليوم:
❓ هل تكتب الكود قبل فهم السؤال؟
قاعدة مهمة:
كل استعلام SQL
هو ترجمة لسؤال بشري.
إذا كان السؤال ضعيفاً،
فالاستعلام سيكون ضعيفاً.
المشكلة غالباً لا تبدأ في الكود،
بل في فهم المطلوب.
قبل أن تكتب:
SELECT
اسأل:
ماذا أريد فعلاً؟
سؤال اليوم:
❓ هل تكتب الكود قبل فهم السؤال؟
📘 الدرس الرابع
ليس كل طلب من الإدارة
يجب تنفيذه حرفياً.
جملة مثل:
"أعطني كل البيانات من بداية النظام"
قد تبدو بسيطة،
لكنها أخطر جملة في قواعد البيانات.
أحياناً المطلوب الحقيقي
جزء صغير جداً من البيانات.
المحترف لا ينفّذ الطلب،
بل يفهمه أولاً.
سؤال:
❓ هل سبق ونفذت طلباً ثم اكتشفت أنه غير منطقي؟
ليس كل طلب من الإدارة
يجب تنفيذه حرفياً.
جملة مثل:
"أعطني كل البيانات من بداية النظام"
قد تبدو بسيطة،
لكنها أخطر جملة في قواعد البيانات.
أحياناً المطلوب الحقيقي
جزء صغير جداً من البيانات.
المحترف لا ينفّذ الطلب،
بل يفهمه أولاً.
سؤال:
❓ هل سبق ونفذت طلباً ثم اكتشفت أنه غير منطقي؟
❤1
📘 الدرس الخامس
مفهوم مهم:
الاستعلام قد يكون:
✔️ صحيح تقنياً
❌ سيئ عملياً
ليس كل كود يعمل
يعتبر كوداً جيداً.
الجودة في SQL
لا تُقاس بعدد السطور،
بل بمدى مناسبته للمطلوب.
سؤال :
❓ كيف تعرف أن الاستعلام “جيد”؟
مفهوم مهم:
الاستعلام قد يكون:
✔️ صحيح تقنياً
❌ سيئ عملياً
ليس كل كود يعمل
يعتبر كوداً جيداً.
الجودة في SQL
لا تُقاس بعدد السطور،
بل بمدى مناسبته للمطلوب.
سؤال :
❓ كيف تعرف أن الاستعلام “جيد”؟
تعلم قواعد بيانات SQL Database
معك خطوة بخطوة من الصفر حتى الاحتراف
🔹 SQL Server
🔹 أمثلة عملية
🔹 تمارين حقيقية
🔹 أخطاء شائعة
🔹 محتوى مستمر
معك خطوة بخطوة من الصفر حتى الاحتراف
🔹 SQL Server
🔹 أمثلة عملية
🔹 تمارين حقيقية
🔹 أخطاء شائعة
🔹 محتوى مستمر
📘 الدرس السادس
البطء في النظام
لا يعني دائماً مشكلة في SQL.
أحياناً يكون السبب:
- طلب غير منطقي
- تقرير غير ضروري
- فهم خاطئ للمطلوب
قبل أن تحسّن الكود،
اسأل:
هل المطلوب نفسه صحيح؟
سؤال:
❓ كم مرة حسّنت استعلاماً كان يجب إلغاءه؟
البطء في النظام
لا يعني دائماً مشكلة في SQL.
أحياناً يكون السبب:
- طلب غير منطقي
- تقرير غير ضروري
- فهم خاطئ للمطلوب
قبل أن تحسّن الكود،
اسأل:
هل المطلوب نفسه صحيح؟
سؤال:
❓ كم مرة حسّنت استعلاماً كان يجب إلغاءه؟
اجابه الدرس الخامس
كيف تعرف أن الاستعلام “جيد”؟
قلنا سابقاً:
الاستعلام قد يكون صحيحاً تقنياً
لكنه سيئ عملياً.
لكن كيف نقيس الجودة؟
الاستعلام الجيد يحقق 4 شروط:
1️⃣ يعيد البيانات الصحيحة فقط
2️⃣ لا يعيد بيانات زائدة
3️⃣ يعمل بكفاءة مناسبة
4️⃣ سهل الفهم والتعديل لاحقاً
مثال:
SELECT * FROM orders;
هل هو صحيح؟
نعم.
هل هو جيد دائماً؟ لا.
لأنه: - يعيد كل الأعمدة حتى غير المطلوبة
- قد يستهلك ذاكرة بلا داعي
- قد يُستخدم في غير سياقه
النسخة الأفضل غالباً تكون:
SELECT order_id, total, order_date
FROM orders
WHERE order_date >= '2025-01-01';
الجودة ليست في أن الكود يعمل،
بل في أنه مناسب للهدف بدقة.
إجابة سؤال اليوم:
الاستعلام الجيد هو الذي
يحقق المطلوب بدقة،
بأقل موارد ممكنة،
وبأبسط منطق واضح.
كيف تعرف أن الاستعلام “جيد”؟
قلنا سابقاً:
الاستعلام قد يكون صحيحاً تقنياً
لكنه سيئ عملياً.
لكن كيف نقيس الجودة؟
الاستعلام الجيد يحقق 4 شروط:
1️⃣ يعيد البيانات الصحيحة فقط
2️⃣ لا يعيد بيانات زائدة
3️⃣ يعمل بكفاءة مناسبة
4️⃣ سهل الفهم والتعديل لاحقاً
مثال:
SELECT * FROM orders;
هل هو صحيح؟
نعم.
هل هو جيد دائماً؟ لا.
لأنه: - يعيد كل الأعمدة حتى غير المطلوبة
- قد يستهلك ذاكرة بلا داعي
- قد يُستخدم في غير سياقه
النسخة الأفضل غالباً تكون:
SELECT order_id, total, order_date
FROM orders
WHERE order_date >= '2025-01-01';
الجودة ليست في أن الكود يعمل،
بل في أنه مناسب للهدف بدقة.
إجابة سؤال اليوم:
الاستعلام الجيد هو الذي
يحقق المطلوب بدقة،
بأقل موارد ممكنة،
وبأبسط منطق واضح.
إجابة الدرس السادس
متى لا تكون المشكلة في SQL؟
في الدرس السابق تعلّمنا كيف نقيس جودة الاستعلام.
اليوم ننتقل خطوة أعمق:
أحياناً يكون الاستعلام جيداً،
لكن النظام بطيء.
كيف؟
لأن المشكلة لم تكن في الكود،
بل في الطلب نفسه.
مثال:
الإدارة تطلب:
“تقرير بكل العمليات منذ بداية النظام”
المبرمج يكتب استعلاماً منظماً،
يحدد الأعمدة،
يستخدم WHERE مناسب.
ومع ذلك:
التقرير يستغرق 40 ثانية.
هل الخطأ في SQL؟
غالباً لا.
الخطأ في السؤال.
السؤال الصحيح كان:
“نريد تقرير آخر 3 أشهر”
عندما يكون السؤال غير منطقي،
لن ينقذك أي تحسين أداء.
إجابة سؤال اليوم:
كثيراً ما نحسّن استعلاماً
كان يجب أن نعيد التفكير في هدفه من البداية.
متى لا تكون المشكلة في SQL؟
في الدرس السابق تعلّمنا كيف نقيس جودة الاستعلام.
اليوم ننتقل خطوة أعمق:
أحياناً يكون الاستعلام جيداً،
لكن النظام بطيء.
كيف؟
لأن المشكلة لم تكن في الكود،
بل في الطلب نفسه.
مثال:
الإدارة تطلب:
“تقرير بكل العمليات منذ بداية النظام”
المبرمج يكتب استعلاماً منظماً،
يحدد الأعمدة،
يستخدم WHERE مناسب.
ومع ذلك:
التقرير يستغرق 40 ثانية.
هل الخطأ في SQL؟
غالباً لا.
الخطأ في السؤال.
السؤال الصحيح كان:
“نريد تقرير آخر 3 أشهر”
عندما يكون السؤال غير منطقي،
لن ينقذك أي تحسين أداء.
إجابة سؤال اليوم:
كثيراً ما نحسّن استعلاماً
كان يجب أن نعيد التفكير في هدفه من البداية.
❤1
فهم المطلوب (60% من الوقت) ← تصميم الاستعلام (30%) ← الكتابة (10%)