Paano ka bumubuo ng mga schema sa MongoDB?

Question

Accepted Answer

MongoDB schema design ay nakasentro sa isang pangunahing desisyon: **embedding** (pag-store ng related data sa loob ng isang document) vs **referencing** (pag-store ng related data sa hiwalay na mga document/collection na may mga reference). Hindi tulad ng SQL na nag-normalize nang default, ang MongoDB design ay nag-optimize para sa kung paano ang data ay *accessible*.

## Embedding — ipon ang 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** ay nagpapanatili ng related data sa isang document — basahin lahat ito sa isang query (mabilis, walang joins). Mabuti para sa data na accessible together at "contains" na mga relasyon.

## Referencing — mag-link ng hiwalay na mga document

```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** ay nag-store ng data nang hiwalay at nag-link sa pamamagitan ng id (tulad ng foreign key) — query nang hiwalay o sumali sa `$lookup`.

## Kailan mag-embed vs 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)
```

## Disenyo para sa access patterns (ang pangunahing prinsipyo)

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

## Bakit ito mahalaga

Ang schema design ay napakahalaga sa MongoDB — ito ay iba mula sa at arguably mas mahalaga kaysa sa SQL, dahil ang MongoDB's flexible document model ay nagbibigay sa iyo ng mga pagpipilian na lubhang nakakaasenso sa performance at maintainability, kaya ang pag-unawa dito ay essential para sa pagbuo ng epektibong MongoDB applications.

Ang pangunahing desisyon — **embedding vs referencing** — ay ang naglalahay ng MongoDB design choice: **embedding** (pag-store ng related data sa loob ng isang document) ay nagpapahintulot ng mabilis na single-query reads ng related data (walang joins) at angkop sa data na accessible together at "contains" na relasyon, habang **referencing** (pag-link ng hiwalay na mga document sa pamamagitan ng id) ay angkop sa malaki/unbounded data, independently-accessed data, at shared/many na relasyon.

Pag-unawa sa **kailan gamitin ang bawat isa** (embed para sa bounded, together-accessed, owned data; reference para sa malaki/lumalaki, independent, shared, o many na relasyon — at maging mindful sa MongoDB's 16MB document size limit) ay ang susi sa kasanayan.

Pinakamahalagang, pag-unawa sa guiding principle — **disenyo para sa access patterns** (isaayos ang data sa paligid ng *paano mo ito que-query*, kaya ang common queries ay efficient, madalas isang document read, sa halip na mag-normalize nang default tulad ng SQL) — ay kung ano ang nag-distinguish sa magandang MongoDB schema design.

Maaaring ibig sabihin nito ang pagtanggap ng ilang **denormalization** (duplication) para sa read efficiency, isang trade-off laban sa update complexity na acceptable at madalas na tama sa MongoDB.

Dahil ang schema design ay lubhang nakakaapekto sa MongoDB application performance at maintainability (isang mahabang embed/reference choice ay nagiging sanhi ng mga mabagal na query, malaking mga document, o update complexity), at dahil ang access-pattern-driven, embed-vs-reference approach ay fundamentally iba mula sa SQL normalization, ang pag-unawa sa MongoDB schema design — ang embed/reference decision, kailan gamitin ang bawat isa, at pag-disenyo para sa access patterns — ay essential, high-value na kaalaman para sa pagbuo ng epektibong MongoDB applications, isa sa pinakamahalaga at distinctive MongoDB topics na nag-separate sa mga bumubuo ng magandang document schemas mula sa mga naive na nag-port ng relational designs.