आप MongoDB में schemas कैसे design करते हैं?

Question

Accepted Answer

MongoDB schema design एक प्रमुख निर्णय पर केंद्रित है: **embedding** (related data को एक document के अंदर संग्रहीत करना) बनाम **referencing** (related data को references के साथ अलग documents/collections में संग्रहीत करना)। SQL के normalize-by-default के विपरीत, MongoDB design इस बात के लिए optimize करता है कि डेटा को *कैसे* access किया जाता है।

## Embedding — related data को एक साथ संग्रहीत करना

```js
// embed related data within the document
{
  _id: ObjectId("..."),
  name: "Ann",
  address: { city: "NY", zip: "10001" },        // embedded sub-document
  orders: [                                      // embedded array of orders
    { product: "Phone", amount: 999 },
    { product: "Case", amount: 20 }
  ]
}
// → ONE query gets the user AND their address AND orders (no joins)
```

**Embedding** related data को एक document में रखता है — इसे एक ही query में पढ़ें (तेज, कोई joins नहीं)। एक साथ access किए जाने वाले डेटा और "contains" relationships के लिए अच्छा।

## Referencing — अलग documents को link करना

```js
// store a reference (id) to a document in another collection
{ _id: ObjectId("u1"), name: "Ann" }                          // users collection
{ _id: ObjectId("o1"), userId: ObjectId("u1"), product: "Phone" } // orders collection
// → query orders by userId; use $lookup to join when needed
```

**Referencing** डेटा को अलग से संग्रहीत करता है और id द्वारा link करता है (foreign key की तरह) — अलग से query करें या `$lookup` के साथ join करें।

## कब embed करें बनाम reference करें

```text
EMBED when:
  ✓ data is accessed TOGETHER (read the parent → you want the children)
  ✓ a "contains"/ownership relationship (address, order line items)
  ✓ the embedded data is bounded (not unboundedly growing)
  ✓ one-to-few relationships

REFERENCE when:
  ✓ data is large or grows UNBOUNDEDLY (avoid huge documents — 16MB doc limit!)
  ✓ data is accessed/updated INDEPENDENTLY
  ✓ many-to-many or one-to-many with many
  ✓ the same data is shared/referenced by many documents (avoid duplication)
```

## Access patterns के लिए design करें (प्रमुख सिद्धांत)

```text
MongoDB schema design is driven by HOW YOU QUERY the data, not pure normalization:
  → Structure data so common queries are efficient (often a single document read).
  → "Data that is accessed together should be stored together."
  → This may mean DENORMALIZING (some duplication) for read efficiency — acceptable
    in MongoDB, traded against update complexity.
```

## यह क्यों महत्वपूर्ण है

Schema design MongoDB में अत्यंत महत्वपूर्ण है — यह SQL से भिन्न है और यकीनन उससे अधिक परिणामी है, क्योंकि MongoDB का flexible document model आपको ऐसे विकल्प देता है जो performance और maintainability को महत्वपूर्ण रूप से प्रभावित करते हैं, इसलिए इसे समझना प्रभावी MongoDB applications बनाने के लिए आवश्यक है।

केंद्रीय निर्णय — **embedding बनाम referencing** — परिभाषित MongoDB design विकल्प है: **embedding** (related data को एक document के भीतर संग्रहीत करना) related data के तेज single-query reads (कोई joins नहीं) को सक्षम करता है और एक साथ access किए जाने वाले डेटा तथा "contains" relationships के लिए उपयुक्त है, जबकि **referencing** (अलग documents को id द्वारा link करना) large/unbounded data, स्वतंत्र रूप से access किए जाने वाले डेटा, और shared/many relationships के लिए उपयुक्त है।

**प्रत्येक का उपयोग कब करें** (bounded, एक साथ-access किए गए, owned डेटा के लिए embed; large/growing, स्वतंत्र, shared, या many relationships के लिए reference — और MongoDB की 16MB document size सीमा के प्रति सचेत रहना) को समझना प्रमुख कौशल है।

सबसे महत्वपूर्ण रूप से, मार्गदर्शक सिद्धांत को समझना — **access patterns के लिए design करें** (डेटा को इस बात के आसपास संरचित करें कि *आप इसे कैसे query करते हैं*, ताकि सामान्य queries कुशल हों, अक्सर एक single document read, बजाय SQL की तरह डिफ़ॉल्ट रूप से normalizing के) — वह है जो अच्छे MongoDB schema design को अलग करता है।

इसका अर्थ read efficiency के लिए कुछ **denormalization** (duplication) को स्वीकार करना हो सकता है, update complexity के विरुद्ध एक trade-off जो MongoDB में स्वीकार्य और अक्सर सही है।

चूँकि schema design MongoDB application performance और maintainability को गहराई से प्रभावित करता है (एक खराब embed/reference विकल्प धीमी queries, विशाल documents, या update complexity का कारण बनता है), और चूँकि access-pattern-driven, embed-बनाम-reference दृष्टिकोण SQL normalization से मौलिक रूप से भिन्न है, MongoDB schema design को समझना — embed/reference निर्णय, प्रत्येक का उपयोग कब करें, और access patterns के लिए design करना — प्रभावी MongoDB applications बनाने के लिए आवश्यक, उच्च-मूल्य ज्ञान है, सबसे महत्वपूर्ण और विशिष्ट MongoDB विषयों में से एक जो उन्हें अलग करता है जो अच्छे document schemas design करते हैं उनसे जो भोलेपन से relational designs को port करते हैं।