embedding మరియు referencing మధ్య వ్యత్యాసం ఏమిటి?

Question

Accepted Answer

**Embedding** సంబంధిత డేటాను ఒక డాక్యుమెంట్ *లో* నిల్వ చేస్తుంది (nested); **referencing** దానిని *విడిగా* ఉన్న డాక్యుమెంట్‌లలో id ద్వారా లింక్ చేసి నిల్వ చేస్తుంది. ఇది MongoDB లో ప్రధాన మోడలింగ్ నిర్ణయం, ఇది read performance, డేటా సైజు మరియు update complexity కోసం వేర్వేరు trade-offs కలిగి ఉంది.

## డాక్యుమెంట్ లో nested - 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)
```

## Trade-offs సరిపక్షగా

```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 vs referencing ను అర్థం చేసుకోవడం **MongoDB డేటా మోడలింగ్ యొక్క ప్రధాన నైపుణ్యం**, కనుక ప్రభావవంతమైన MongoDB అప్లికేషన్‌లను రూపొందించడానికి ఇది ముఖ్యమైన జ్ఞానం.

ఈ నిర్ణయం — సంబంధిత డేటాను ఒక డాక్యుమెంట్ లో నిల్వ చేయడం (embedding) విరుద్ధంగా విడిగా లింక్ చేసిన డాక్యుమెంట్‌లలో (referencing) — నేరుగా అప్లికేషన్ యొక్క read performance, డేటా consistency, డాక్యుమెంట్ సైజు మరియు update complexity ను నిర్ణయిస్తుంది, ఇది చాలా ప్రభావవంతమైన MongoDB డిజైన్ ఎంపిక చేస్తుంది.

**Trade-offs** ను అర్థం చేసుకోవడం చాలా ముఖ్యం: **embedding** సంబంధిత డేటా యొక్క వేగవంతమైన single-query చదవకలను మరియు atomic updates ను ఇస్తుంది ("contains" సంబంధాలు, కలిసి ప్రాప్యత చేయబడిన డేటా, సীమితమైన sub-data కోసం సరిపోతుంది) కానీ duplication (డేటా సంపాదితమైనట్లయితే update complexity), డాక్యుమెంట్ growth (16MB limit ను ప్రమాదపరిచేది, unbounded ఉంటే) కారణమవుతుంది; **referencing** డేటాను ఒక్కసారి నిల్వ చేస్తుంది (సులభమైన updates, duplication లేదు, సైజు సమస్యలు లేవు, స్వతంత్ర నిర్వహణ) కానీ సంయోజించడానికి బహుళ queries లేదా `$lookup` ను అవసరం చేస్తుంది (సంబంధిత-డేటా చదవకలు నెమ్మదిగా ఉంటాయి).

ఏ సిద్ధాంతం ఏ పరిస్థితికి సరిపోతుందో తెలుసుకోవడం — bounded, owned, కలిసి-ప్రాప్యత చేయబడిన డేటా కోసం embed చేయండి; పెద్ద, పంచిన, స్వతంత్ర లేదా అనేక సంబంధాల కోసం reference చేయండి — ఇది ముఖ్యమైన మోడలింగ్ నిర్ణయం.

సాధారణ **hybrid approach** ను అర్థం చేసుకోవడం (వేగవంతమైన చదవకల కోసం subset embed చేయడం, పూర్తి డేటా కోసం reference చేయడం — రెండింటి యొక్క మంచిది పొందడం) అధునాతన డిజైన్ ను ప్రతిబింబిస్తుంది.

ఈ నిర్ణయం MongoDB అప్లికేషన్ quality ను తీవ్రంగా ప్రభావితం చేస్తుందని (తప్పుడు ఎంపికలు నెమ్మదిమైన queries, bloated documents లేదా బాధాకరమైన updates కారణమవుతాయి), మరియు ఇది ఫండమెంటల్, విశిష్ట MongoDB మోడలింగ్ నైపుణ్యం (నేరుగా SQL సమానతకు లేనిది — SQL డిఫాల్ట్ ద్వారా normalizes) కాబట్టి, embedding vs referencing ను అర్థం చేసుకోవడం — trade-offs, ప్రతిটిని ఎప్పుడు ఉపయోగించాలి, మరియు hybrid approaches — ముఖ్యమైనది, అధిక-విలువ జ్ఞానం, ఇది ప్రభావవంతమైన MongoDB డేటా మోడలింగ్ యొక్క హృదయంలో ఉంది మరియు అత్యంత ముఖ్యమైన మరియు తరచుగా చర్చించిన MongoDB విషయాలలో ఒకటి, అప్లికేషన్ యొక్క access patterns కోసం చక్కగా కేటాయించిన schemas ను రూపొందించడానికి కేంద్రీయమైనది.