Embedding र referencing को बीच के फरक छ?

Question

Accepted Answer

**Embedding** ले सम्बन्धित डेटा दस्तावेज *भित्र* (नेस्टेड) भण्डार गर्छ; **referencing** ले यसलाई *अलग* दस्तावेजहरूमा id द्वारा लिंक गरी भण्डार गर्छ। यो MongoDB मा मुख्य मडलिङ निर्णय हो, जसमा पढाइ कार्यक्षमता, डेटा आकार, र अपडेट जटिलताको लागि विभिन्न ट्रेड-अफ्स छन्।

## दस्तावेज भित्र नेस्टेड — Embedding

```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 द्वारा लिंक गरी — Referencing

```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
```

## यो किन महत्त्वपूर्ण छ

Embedding बनाम referencing बुझ्नु **MongoDB डेटा मडलिङ को मुख्य कौशल** हो, त्यसैले प्रभावकारी MongoDB अनुप्रयोगहरू डिजाइन गर्नको लागि आवश्यक ज्ञान हो।

यो निर्णय — सम्बन्धित डेटा दस्तावेज भित्र (embedding) भण्डार गर्ने बनाम अलग लिंक गरिएका दस्तावेजहरूमा (referencing) — सीधै अनुप्रयोगको पढाइ कार्यक्षमता, डेटा सुसंगतता, दस्तावेज आकार, र अपडेट जटिलता निर्धारण गर्छ, यसलाई सबैभन्दा महत्त्वपूर्ण MongoDB डिजाइन छनोट बनाते।

**ट्रेड-अफ्स** बुझ्नु कुञ्जी हो: **embedding** ले सम्बन्धित डेटाको द्रुत एकल-क्वेरी पढाइ र परमाणु अपडेट ("contains" सम्बन्ध, एकसाथ पहुँच गरिएको डेटा, सीमित उप-डेटाको लागि उपयुक्त) दिन्छ तर नक्कल (अपडेट जटिलता यदि डेटा साझा छ) र दस्तावेज वृद्धि (यदि असीमित छ भने 16MB सीमामा जोखिम) गर्छ; **referencing** डेटा एकपटक भण्डार गर्छ (सहज अपडेट, कुनै नक्कल छैन, कुनै आकार समस्या छैन, स्वतन्त्र प्रबन्धन) तर एकसाथ गर्नको लागि बहु-क्वेरी वा `$lookup` चाहिन्छ (सम्बन्धित-डेटा पढाइ ढिलो)।

कुन परिस्थितिमा कुन फिट हुन्छ भनेर जान्नु — सीमित, स्वामित्व, एकसाथ पहुँच गरिएको डेटाको लागि embed गर्नु; ठूलो, साझा, स्वतन्त्र, वा धेरै सम्बन्धको लागि reference गर्नु — आवश्यक मडलिङ निर्णय हो।

सामान्य **हाइब्रिड दृष्टिकोण** (द्रुत पठनको लागि उप-डेटा नेस्ट गर्नु जबकि पूर्ण डेटाको लागि reference गर्नु — दुवैको सर्वश्रेष्ठ पाउनु) बुझ्नु परिष्कृत डिजाइन प्रतिबिम्बित गर्छ।

यो निर्णय MongoDB अनुप्रयोग गुणस्तरलाई गहिराइ सम्म प्रभावित गर्छ (गलत छनोटले ढिलो क्वेरी, फूलिएका दस्तावेज, वा कष्टदायक अपडेट गर्छ), र यो मौलिक, विशिष्ट MongoDB मडलिङ कौशल हो (SQL बराबरको कुरा छैन — SQL पूर्वनिर्धारितद्वारा सामान्यीकरण गर्छ), embedding बनाम referencing बुझ्नु — ट्रेड-अफ्स, प्रत्येकको प्रयोग कहिले गर्ने, र हाइब्रिड दृष्टिकोण — आवश्यक, उच्च-मूल्य ज्ञान हो जो प्रभावकारी MongoDB डेटा मडलिङको केन्द्रमा छ र अनुप्रयोगको पहुँच प्यामको लागि राम्रोसँग कार्यप्रदर्शन गर्ने स्कीमा डिजाइन गर्न सबैभन्दा महत्त्वपूर्ण र बारम्बार छलफल गरिने MongoDB विषयहरूमा एक हो।