MongoDB मा schemas कसरी डिजाइन गर्नुहुन्छ?

Question

Accepted Answer

MongoDB schema design एक मुख्य निर्णयमा केन्द्रित छ: **embedding** (सम्बन्धित डेटा एक डकुमेन्ट भित्र राख्ने) बनाम **referencing** (सम्बन्धित डेटा अलग डकुमेन्ट/कलेक्सन मा राख्ने र सन्दर्भ गर्ने)। SQL को normalize-by-default को विपरीत, MongoDB डिजाइन डेटा कसरी *एक्सेस गरिन्छ* भन्नेको लागि अनुकूलन गर्छ।

## Embedding — सम्बन्धित डेटा एकसाथ राख्नु

```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** सम्बन्धित डेटा एक डकुमेन्टमा राख्छ — यो एकै पूछताछमा पढ्नुहोस् (छिटो, कुनै joins छैन)। डेटाको लागि राम्रो जो एकसाथ एक्सेस गरिन्छ र "contains" सम्बन्धको लागि।

## Referencing — अलग डकुमेन्ट लिङ्क गर्नु

```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 द्वारा लिङ्क गर्छ (विदेशी कुञ्जीजस्तो) — अलग पूछताछ गर्नुहोस् वा `$lookup` सँग जोडनुहोस्।

## कहिले 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)
```

## एक्सेस प्याटर्नको लागि डिजाइन गर्नु (मुख्य सिद्धान्त)

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

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

MongoDB मा schema डिजाइन अत्यन्त महत्त्वपूर्ण छ — यो SQL मा भन्दा फरक छ र तर्कतः अधिक महत्त्वपूर्ण छ, किनकि MongoDB को लचकदार डकुमेन्ट मडेलले तपाईंलाई विकल्पहरु दिन्छ जो कार्यक्षमता र अनुरक्षणीयतालाई महत्त्वपूर्ण रूपमा प्रभाव गर्छ, त्यसैले यो बुझ्नु प्रभावकारी MongoDB अनुप्रयोग निर्माणको लागि आवश्यक छ।

मुख्य निर्णय — **embedding बनाम referencing** — MongoDB डिजाइन छनोटको परिभाषा गर्ने छ: **embedding** (एक डकुमेन्ट भित्र सम्बन्धित डेटा राख्ने) सम्बन्धित डेटा को छिटो एकल-पूछताछ पढ्न सक्षम गर्छ (कुनै joins छैन) र डेटा एकसाथ एक्सेस गरिने र "contains" सम्बन्धको लागि उपयुक्त छ, जबकि **referencing** (अलग डकुमेन्ट id द्वारा लिङ्क गर्ने) ठूलो/सीमाहीन डेटा, स्वतन्त्र रूपमा एक्सेस गरिने डेटा, र साझा/धेरै सम्बन्धको लागि उपयुक्त छ।

**कहिले प्रत्येक प्रयोग गर्नु** बुझ्नु (bounded, एकसाथ एक्सेस गरिने, मालिकानाको डेटाको लागि embed गर्नु; ठूलो/बढ्दो, स्वतन्त्र, साझा, वा धेरै सम्बन्धको लागि reference गर्नु — र MongoDB को 16MB डकुमेन्ट साइज सीमा को बारे मा सचेत रहनु) मुख्य कुशलता हो।
abन्दै महत्त्वपूर्ण, निर्देशन सिद्धान्त बुझ्नु — **एक्सेस प्याटर्नको लागि डिजाइन गर्नु** (डेटा संरचना *कसरी पूछताछ गर्नुहुन्छ* वरिपरि, त्यसैले सामान्य पूछताछहरु दक्ष छन्, अक्सर एकल डकुमेन्ट पढ्न, SQL जस्तो सामान्यीकरण गर्नको सट्टा) — राम्रो MongoDB schema डिजाइनलाई अलग गर्ने कुरा हो।

यो केहि **denormalization** (दुहराव) पढ्न दक्षताको लागि स्वीकार गर्ने अर्थ हुन सक्छ, अद्यतन जटिलता विरुद्ध एक व्यापार जो स्वीकार्य र अक्सर MongoDB मा सही छ।

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