إطار اتخاذ قرارات تصميم المخطط
سيطبّق المتعلمون قائمة تحقق منظمة تشمل أنماط الاستعلام وتواتر الكتابة ونمو المستند، لاختيار التضمين أو الإحالة لأي مجال.
إطار اتخاذ قرارات تصميم المخطط درس مجاني في MongoDB Academy على CoddyKit. هذا هو الدرس 4 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في MongoDB Academy، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة MongoDB Academy 4 دروس في المجموع.
أهمية إطار اتخاذ القرار
تمنحك مرونة مخطط MongoDB قوة كبيرة، لكنها قد تؤدي إلى الحيرة في التحليل. هل ينبغي لك التضمين أم استخدام المراجع؟ ومتى لا يكون الخيار واضحًا؟ يستبدل إطار اتخاذ القرار المنظم التخمين بقائمة تحقق قابلة للتكرار. ومن خلال طرح الأسئلة نفسها حول أنماط الاستعلام، وتكرار الكتابة، ونمو المستند، يمكنك الوصول إلى المخطط المناسب لأي مجال باستمرار.
الخطوة 1: تحديد أنماط الاستعلام
ابدأ بإدراج استعلامات القراءة الأكثر تكرارًا التي ينفذها تطبيقك. واسأل: هل تحتاج هذه الاستعلامات دائمًا إلى الأصل والأبناء معًا، أم يُستعلم عن الأبناء بصورة مستقلة؟ إذا كانت بيانات الابن تُجلب دائمًا تقريبًا مع أصله، فإن التضمين يلغي رحلة ذهاب وإياب. أما إذا كان يُستعلم عن الأبناء أو يُرتبون أو تُطبّق عليهم التصفية بصورة متكررة، فإن استخدام المراجع يبقي الاستعلامات بسيطة والفهارس مركزة.
الخطوة 2: تقدير حجم البيانات ونموها
لكل مصفوفة أو بنية متداخلة محتملة، اسأل: كم عنصرًا ستحتوي عليه في حالة الاستقرار، وهل يمكن أن تنمو بلا حدود؟ استخدم قواعد عمل تقريبية: نادرًا ما يملك المستخدم أكثر من 5 عناوين (ضمّنها)، لكنه قد يكتب آلاف المراجعات (استخدم المراجع). وأي شيء له حد أقصى غير محدود أو غير معروف يُعد مرشحًا للنقل إلى مجموعة منفصلة.
الخطوة 3: تقييم تكرار الكتابة
ضع في اعتبارك مدى تكرار كتابة بيانات الابن مقارنةً بالأصل. يعني التضمين أن كل تحديث للابن يعيد كتابة مستند الأصل، مما يؤدي إلى نقله في التخزين إذا نما المستند. فإذا كان الأبناء يُحدَّثون كثيرًا وبصورة مستقلة عن الأصل، فإن عبء إعادة كتابة الأصل في كل مرة يرجّح استخدام المراجع—إذ تُحدَّث مستندات الأبناء في مواضعها من دون لمس الأصل إطلاقًا.
الخطوة 4: التحقق من مشاركة البيانات
اسأل ما إذا كانت بيانات الابن مملوكة لأصل واحد أم مشتركة بين عدة أصول. فالعنوان مملوك لمستخدم واحد، ولذلك من الآمن تضمينه. أما المنتج في الكتالوج فقد تشير إليه آلاف الطلبات، لذا يجب أن يكون في مجموعته الخاصة لتجنب تكرار البيانات وتقادمها. وينبغي دائمًا استخدام المراجع للبيانات المشتركة، لا تضمينها.
الخطوة 5: تقييم متطلبات الذرية
يضمن MongoDB الكتابات الذرية على مستوى المستند مجانًا، من دون الحاجة إلى معاملات. فإذا احتجت إلى تحديث الأصل وأبنائه بصورة ذرية، فإن التضمين يبقيهما في المستند نفسه، وبذلك يكون أي تحديث ذريًا افتراضيًا. أما إذا استخدمت مراجع بين مجموعتين واحتجت إلى الذرية، فيجب عليك استخدام معاملة متعددة المستندات، مما يضيف زمن تأخير وتعقيدًا.
جدول قرارات إطار العمل
طبّق هذه القواعد بالترتيب:
- يُجلب الأبناء دائمًا مع الأب، وعددهم قليل، ويمتلكهم الأب: التضمين EMBED
- يُستعلم عن الأبناء بشكل مستقل أو تتم مشاركتهم: المرجع REFERENCE
- يمكن أن ينمو عدد الأبناء بلا حدود: المرجع REFERENCE (أو نمط التجميع في مجموعات)
- يلزم إجراء تحديث ذري عبر الأب والأبناء: التضمين EMBED (أو معاملة)
- تواتر الكتابة على الأبناء مرتفع مقارنةً بالأب: المرجع REFERENCE
إذا تعارضت عدة قواعد، فالإشارة بالمرجع هي الخيار الافتراضي الأكثر أمانًا.
مثال: مخطط طلبات التجارة الإلكترونية
طبّق هذا الإطار على طلب في نظام للتجارة الإلكترونية. عناصر الطلب: تُجلب دائمًا مع الطلب، وعددها قليل (أقل من 50)، ويمتلكها الطلب ← التضمين. عنوان الشحن: لقطة محفوظة وقت الطلب ولا تتم مشاركته مطلقًا ← التضمين. العميل: مشترك بين آلاف الطلبات ← المرجع. كتالوج المنتجات: مشترك بين الطلبات ويُحدَّث بشكل مستقل ← المرجع.
db.orders.insertOne({
_id: ObjectId(),
customerId: ObjectId('c1'), // reference — shared data
shippingAddress: { // embed — point-in-time snapshot
street: '123 Maple St',
city: 'Austin'
},
items: [ // embed — small, owned by order
{ productId: ObjectId('p1'), qty: 2, price: 19.99, name: 'Widget' }
]
});مثال: مخطط وسائل التواصل الاجتماعي
طبّق هذا الإطار على منشور في وسائل التواصل الاجتماعي. مؤلف المنشور: مشترك بين المنشورات ← المرجع. نص المنشور وبياناته الوصفية: يمتلكهما المنشور وحجمهما صغير ← التضمين. الإعجابات (العدد فقط): حقل رقمي ← التضمين كعداد. التعليقات: قد يصل عددها إلى الآلاف، ويُستعلم عنها ويُقسّم إلى صفحات بشكل مستقل ← المرجع في مجموعة comments منفصلة.
db.posts.insertOne({
_id: ObjectId(),
authorId: ObjectId('u1'), // reference
title: 'Why MongoDB rocks',
body: '<p>Because documents...</p>',
tags: ['mongodb', 'nosql'], // embed — small, owned
likesCount: 0, // embed — simple counter
createdAt: new Date()
// comments live in db.comments, NOT embedded here
});تطوير مخططك بمرور الوقت
قد لا يكون المخطط المناسب عند الإطلاق هو المخطط المناسب عند التوسع. ابدأ بأبسط تصميم صحيح. إذا اكتشفت لاحقًا أن مصفوفة مضمّنة تنمو بشكل مفرط، فانقلها إلى مجموعة منفصلة. يتيح مخطط MongoDB المرن التطور التدريجي؛ إذ يمكنك كتابة مستندات جديدة بالبنية الجديدة مع الإبقاء على المستندات القديمة، ثم ملء البيانات بأثر رجعي باستخدام نص ترحيل.
توثيق قرارات تصميم المخطط
دوّن أسباب كل اختيار في المخطط بينما لا تزال واضحة في ذاكرتك. إن إضافة تعليق في ملف مخطط Mongoose أو مستند تصميم مختصر يشرح سبب تضمين items والإشارة إلى customerId بالمرجع تحقق فوائد كبيرة عندما ينضم مهندس جديد إلى الفريق أو عندما تعود إلى المخطط بعد ستة أشهر. تصميم المخطط عمل مقصود وليس أمرًا عشوائيًا.
const orderSchema = new mongoose.Schema({
customerId: { type: mongoose.Schema.Types.ObjectId, ref: 'Customer' }, // reference: shared
shippingAddress: addressSchema, // embed: point-in-time snapshot
items: [lineItemSchema], // embed: small, always with order
status: { type: String, enum: ['pending', 'shipped', 'delivered'] },
createdAt: { type: Date, default: Date.now }
});اختبار سريع
اختبر مدى فهمك لمفاهيم MongoDB وقواعد بيانات NoSQL التي تناولها هذا الدرس.
مراجعة الدرس
في هذا الدرس تعلمت أن: إطار القرار ذي الخطوات الخمس يغطي أنماط الاستعلام وحجم البيانات وتواتر الكتابة والمشاركة والذرية، وأن البيانات المشتركة تنتمي دائمًا إلى مجموعة منفصلة تتم الإشارة إليها بالمرجع، وأن قرارات تصميم المخطط ينبغي توثيقها إلى جانب الشيفرة. بعد ذلك سنستكشف التحقق من المخطط باستخدام JSON Schema لفرض جودة البيانات في مجموعات MongoDB.
تعلم JavaScript مع معلم ذكاء اصطناعي — مجانًا
اكتب وقم بتشغيل أكوادك الفعلية في المتصفح، واحصل على مساعدة فورية من معلم ذكاء اصطناعي متاح 24/7، واستمر من حيث توقفت على الويب أو في التطبيق.
- الدورات
- 30
- الدروس
- 120
الأسئلة الشائعة
هل درس «إطار اتخاذ قرارات تصميم المخطط» مجاني؟
نعم — نص درس «إطار اتخاذ قرارات تصميم المخطط» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة MongoDB Academy، انتقل إلى CoddyKit PRO. تتضمن دورة MongoDB Academy 4 دروس في المجموع.
ماذا ستتعلم في «إطار اتخاذ قرارات تصميم المخطط»؟
سيطبّق المتعلمون قائمة تحقق منظمة تشمل أنماط الاستعلام وتواتر الكتابة ونمو المستند، لاختيار التضمين أو الإحالة لأي مجال. تتمرن على MongoDB Academy مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.
هل أحتاج إلى خبرة سابقة لأبدأ MongoDB Academy؟
لا تُشترط خبرة سابقة. MongoDB Academy على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 4 من أصل 4.
كم من الوقت يستغرق درس «إطار اتخاذ قرارات تصميم المخطط»؟
معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.
هل يمكنني كتابة وتشغيل أكواد في درس MongoDB Academy هذا؟
نعم. كل درس في MongoDB Academy يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.
جميع الدروس في هذه الدورة
- التضمين: علاقات واحد إلى عدد قليل
- الإحالة: علاقات واحد إلى متعدد ومتعدد إلى متعدد
- النمط المضاد للمصفوفة غير محدودة الحجم
- إطار اتخاذ قرارات تصميم المخطط