ما هو الفرق بين التضمين (Embedding) والإشارة (Referencing)؟

Question

Accepted Answer

**التضمين** يخزن البيانات ذات الصلة *داخل* المستند (متداخلة)؛ **الإشارة** تخزنها في *مستندات منفصلة* مرتبطة بـ id. هذا هو القرار الأساسي للنمذجة في MongoDB، مع مقاييس مختلفة لأداء القراءة وحجم البيانات وتعقيد التحديثات.

## التضمين — متداخل داخل المستند

```js
{
  _id: ObjectId("..."),
  title: "My Post",
  author: { name: "Ann", email: "ann@x.com" },   // EMBEDDED author
  comments: [                                      // EMBEDDED comments
    { user: "Bob", text: "Great!" },
    { user: "Carol", text: "Thanks" }
  ]
}
// ✓ ONE query gets the post + author + comments (fast, atomic)
// ✗ if author info changes, must update it in every post embedding it (duplication)
// ✗ document grows with comments → could hit the 16MB limit if unbounded
```

## الإشارة — مستندات منفصلة مرتبطة بـ id

```js
// posts collection
{ _id: ObjectId("p1"), title: "My Post", authorId: ObjectId("u1") }
// users collection
{ _id: ObjectId("u1"), name: "Ann", email: "ann@x.com" }
// comments collection
{ _id: ObjectId("c1"), postId: ObjectId("p1"), user: "Bob", text: "Great!" }

// ✓ author/comments stored ONCE, updated in one place; no document-size issues
// ✓ each entity managed independently
// ✗ need multiple queries or $lookup to combine (slower reads for related data)
```

## المقاييس جنباً إلى جنب

```text
                  Embedding                    Referencing
Reads             ✓ fast (one query)           ✗ multiple queries / $lookup
Data duplication  ✗ duplicated (update many)   ✓ stored once
Document size     ✗ grows (16MB limit risk)    ✓ no size concern
Updates           ✗ update in every copy       ✓ update in one place
Atomicity         ✓ atomic (single document)   ✗ across documents
Best for          contains, accessed-together  shared, large, independent, many
```

## نهج هجين (شائع)

```js
// embed a SUBSET for fast reads, reference for the full data
{ title: "Post", author: { _id: ObjectId("u1"), name: "Ann" } }  // enough for display
// → reference (author._id) for full details when needed; embed name for the common read
```

## لماذا يهم هذا

فهم التضمين مقابل الإشارة هو **المهارة الأساسية لنمذجة بيانات MongoDB**، لذا فهو معرفة أساسية لتصميم تطبيقات MongoDB فعالة.

هذا القرار — تخزين البيانات ذات الصلة داخل مستند (التضمين) مقابل مستندات منفصلة مرتبطة (الإشارة) — يحدد بشكل مباشر أداء القراءة في التطبيق واتساق البيانات وحجم المستند وتعقيد التحديثات، مما يجعله أهم قرار تصميم في MongoDB.

فهم **المقاييس** هو المفتاح: **التضمين** يوفر قراءات سريعة من استعلام واحد للبيانات ذات الصلة والتحديثات الذرية (مناسب لعلاقات "يحتوي على"، البيانات المُدمجة معاً، البيانات الفرعية المحدودة) لكنه يسبب تكراراً (تعقيد التحديثات إذا كانت البيانات مشتركة) ونمواً للمستند (يخاطر بحد 16 ميجابايت إذا كانت غير محدودة)؛ **الإشارة** تخزن البيانات مرة واحدة (تحديثات سهلة، بدون تكرار، بدون مشاكل حجم، إدارة مستقلة) لكن تتطلب عدة استعلامات أو `$lookup` للجمع (قراءات أبطأ للبيانات المرتبطة).

معرفة أي منهما يناسب أي سيناريو — ضمّن البيانات المحدودة والمملوكة والمُستخدمة معاً؛ أشر إلى البيانات الكبيرة والمشتركة والمستقلة أو العلاقات الكثيرة — هي الحكمة النمذجة الأساسية.

فهم **النهج الهجين** الشائع (تضمين مجموعة فرعية للقراءات السريعة مع الإشارة للبيانات الكاملة — الحصول على أفضل ما في كلا الجانبين) يعكس تصميماً متطوراً.

بما أن هذا القرار يؤثر بشكل عميق على جودة تطبيق MongoDB (الخيارات الخاطئة تسبب استعلامات بطيئة أو مستندات منتفخة أو تحديثات مؤلمة)، وبما أنها المهارة النمذجة الأساسية والمميزة في MongoDB (بدون معادل مباشر في SQL — SQL يطبّع بشكل افتراضي)، فإن فهم التضمين مقابل الإشارة — المقاييس ومتى تستخدم كلاً منهما والنهج الهجين — معرفة أساسية وعالية القيمة في قلب نمذجة بيانات MongoDB الفعالة وأحد أهم وأكثر الموضوعات في MongoDB تناقشاً، مركزية لتصميم مخطط بيانات يعمل بكفاءة لأنماط الوصول في التطبيق.