آپ MongoDB میں schemas کو کیسے ڈیزائن کرتے ہیں؟

Question

Accepted Answer

MongoDB schema design ایک کلیدی فیصلے کے گرد مرکوز ہے: **embedding** (متعلقہ ڈیٹا کو ایک دستاویز کے اندر محفوظ کرنا) بمقابلہ **referencing** (متعلقہ ڈیٹا کو الگ دستاویزات/کلیکشنز میں حوالہ جات کے ساتھ محفوظ کرنا)۔ SQL کے normalize-by-default کے برعکس، MongoDB ڈیزائن اس بات کے لیے optimize ہوتا ہے کہ ڈیٹا کو *کیسے رسائی* کی جاتی ہے۔

## 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** متعلقہ ڈیٹا کو ایک دستاویز میں رکھتا ہے — اسے ایک ہی query میں پڑھیں (تیز، کوئی 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 سے منسلک کرتا ہے (جیسے 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)
```

## رسائی کے نمونے کے لیے ڈیزائن کریں (اہم اصول)

```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 کا لچکدار دستاویز ماڈل آپ کو ایسے اختیارات دیتا ہے جو کارکردگی اور برقرائی پر نمایاں اثر ڈالتے ہیں، اس لیے اسے سمجھنا موثر MongoDB ایپلیکیشنز بنانے کے لیے ضروری ہے۔

مرکزی فیصلہ — **embedding بمقابلہ referencing** — MongoDB ڈیزائن کا متعین کرنے والا انتخاب ہے: **embedding** (دستاویز کے اندر متعلقہ ڈیٹا محفوظ کرنا) متعلقہ ڈیٹا کی تیز single-query پڑھائی (کوئی joins نہیں) کو سہل بناتا ہے اور ڈیٹا کے لیے موزوں ہے جو ایک ساتھ رسائی کیا جاتا ہے اور "contains" تعلقات، جبکہ **referencing** (الگ دستاویزات کو id سے منسلک کرنا) بڑے/غیر محدود ڈیٹا، آزادانہ طور پر رسائی شدہ ڈیٹا، اور shared/many تعلقات کے لیے موزوں ہے۔

ہر ایک کے استعمال کا **وقت** سمجھنا (embed کریں محدود، ایک ساتھ رسائی شدہ، مالک شدہ ڈیٹا کے لیے؛ reference کریں بڑے/بڑھتے ہوئے، آزاد، shared، یا many تعلقات کے لیے — اور MongoDB کی 16MB دستاویز سائز کی حد سے واقفیت رکھتے ہوئے) کلیدی مہارت ہے۔

ey سے زیادہ اہم، رہنما اصول سمجھنا — **رسائی کے نمونے کے لیے ڈیزائن کریں** (ڈیٹا کو اس گرد structure کریں *آپ اسے کیسے query کرتے ہیں*، تاکہ عام queries موثر ہوں، اکثر ایک دستاویز پڑھائی، SQL کی طرح normalize کرنے کے بجائے) — یہ ہے جو اچھے MongoDB schema design کو الگ کرتا ہے۔

اس کا مطلب کچھ **denormalization** (دہرائپن) قبول کرنا ہو سکتا ہے پڑھائی کی کارکردگی کے لیے، اپڈیٹ complexity کے خلاف ایک تبادلہ جو MongoDB میں قابل قبول اور اکثر درست ہے۔

چونکہ schema design MongoDB ایپلیکیشن کی کارکردگی اور برقرائی کو گہری طور پر متاثر کرتا ہے (ایک خراب embed/reference انتخاب سست queries، بھاری دستاویزات، یا update complexity کا سبب بنتا ہے)، اور چونکہ access-pattern-driven، embed-vs-reference انقطاع SQL normalization سے بنیادی طور پر مختلف ہے، MongoDB schema design سمجھنا — embed/reference فیصلہ، ہر ایک کا کب استعمال، اور رسائی کے نمونے کے لیے ڈیزائن کرنا — ضروری، اعلیٰ قیمت کا علم ہے موثر MongoDB ایپلیکیشنز بنانے کے لیے، ایک سب سے اہم اور منفرد MongoDB موضوعات جو ان لوگوں کو الگ کرتے ہیں جو اچھی دستاویز schemas ڈیزائن کرتے ہیں ان لوگوں سے جو بیکاری سے relational designs کو منتقل کرتے ہیں۔