तुम MongoDB मध्ये स्कीमा डिজाइन कसे करता?

Question

Accepted Answer

MongoDB स्कीमा डिजाइन एका मुख्य निर्णयावर केंद्रित आहे: **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 द्वारे लिंक करते (विदेशी key प्रमाणे) — वेगळ्या क्वेरी किंवा `$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)
```

## अ‍ॅक्सेस पॅटर्नसाठी डिजाइन करा (मुख्य तत्व)

```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 मध्ये स्कीमा डिजाइन गंभीरपणे महत्वाचा आहे — SQL मधील पेक्षा वेगळा आणि वाद्यतः अधिक परिणामकारी आहे, कारण MongoDB चे लचकदार दस्तऐवज मॉडेल तुम्हाला निर्णय देते जे कार्यप्रदर्शन आणि स्थिरतेवर लक्षणीय परिणाम करते, म्हणून प्रभावी MongoDB अनुप्रयोग तयार करण्यासाठी हे समजून घेणे आवश्यक आहे.

मध्यवर्ती निर्णय — **embedding विरुद्ध referencing** — हा MongoDB डिजाइनचा निर्धारक निर्णय आहे: **embedding** (संबंधित डेटा दस्तऐवजाच्या आंतर्गत संग्रहित करणे) संबंधित डेटाच्या वेगवान एक-क्वेरी वाचनी सक्षम करते (कोणतेही joins नाहीत) आणि एकत्रितपणे अ‍ॅक्सेस केला जातो असे डेटा आणि "contains" संबंध सोबत बसते, तर **referencing** (वेगळ्या दस्तऐवजांना id द्वारे लिंक करणे) मोठे/असीमित डेटा, स्वतंत्रपणे-अ‍ॅक्सेस केलेले डेटा, आणि सामायिक/अनेक संबंधांसाठी बसते.

**कधी प्रत्येक वापर करायचे** हे समजून घेणे (bounded, एकत्रितपणे-अ‍ॅक्सेस केलेल्या, मालकीचा डेटा embed करा; मोठे/वाढणारे, स्वतंत्र, सामायिक, किंवा अनेक संबंधांसाठी reference करा — आणि MongoDB च्या 16MB दस्तऐवज आकारातील मर्यादेचे लक्ष ठेवून) हे मुख्य कौशल्य आहे.

सर्वात महत्वाचे म्हणजे, मार्गदर्शक तत्व समजून घेणे — **अ‍ॅक्सेस पॅटर्नसाठी डिजाइन करा** (डेटा तुम्ही कसे क्वेरी करता त्याभोवती संरचित करा, जेणेकरून सामान्य क्वेरीज कार्यक्षम असतात, बहुतेक वेळा एकच दस्तऐवज वाचन, SQL प्रमाणे normalize करण्याऐवजाय) — हेच MongoDB स्कीमा डिजाइनचे चांगले डिजाइन वेगळे करते.

याचा अर्थ वाचन कार्यक्षमतेसाठी काही **denormalization** (डुप्लिकेशन) स्वीकारणे असू शकते, एक व्यापार-ऑफ अद्यतन जटिलतेच्या विरुद्ध जो MongoDB मध्ये स्वीकार्य आणि अनेकदा योग्य आहे.

स्कीमा डिजाइन MongoDB अनुप्रयोग कार्यप्रदर्शन आणि स्थिरतेवर गहनपणे परिणाम करतो (एक खराब embed/reference निर्णय मंद क्वेरीज, मोठ्या दस्तऐवजांकडे, किंवा अद्यतन जटिलतेकडे नेतो), आणि access-pattern-চালित, embed-vs-reference दृष्टिकोन SQL normalization च्या मूलभूतरित्या वेगळा आहे, म्हणून MongoDB स्कीमा डिजाइन समजून घेणे — embed/reference निर्णय, कधी प्रत्येक वापर करायचे, आणि अ‍ॅक्सेस पॅटर्नसाठी डिजाइन करणे — हा अत्यावश्यक, उच्च-मूल्य ज्ञान आहे प्रभावी MongoDB अनुप्रयोग तयार करण्यासाठी, एक सर्वात महत्वाचा आणि विशिष्ट MongoDB विषय जो चांगले दस्तऐवज स्कीमा डिजाइन करणार्‍यांना त्यांच्यापासून वेगळे करते जे नैवपणे संबंधीय डिजाइन पोर्ट करतात.