Bagaimanakah anda mereka bentuk skema dalam MongoDB?

Question

Accepted Answer

Reka bentuk skema MongoDB berpusat pada satu keputusan utama: **pembenaman (embedding)** (menyimpan data berkaitan di dalam dokumen) vs **rujukan (referencing)** (menyimpan data berkaitan dalam dokumen/koleksi berasingan dengan rujukan). Tidak seperti pendekatan normalkan-secara-lalai SQL, reka bentuk MongoDB mengoptimumkan untuk cara data *diakses*.

## Pembenaman — simpan data berkaitan bersama-sama

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

**Pembenaman** menyimpan data berkaitan dalam satu dokumen — baca semuanya dalam satu pertanyaan (pantas, tiada join). Baik untuk data yang diakses bersama dan hubungan "mengandungi".

## Rujukan — pautkan dokumen berasingan

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

**Rujukan** menyimpan data secara berasingan dan memautkannya mengikut id (seperti kunci asing) — pertanyakan secara berasingan atau sertai dengan `$lookup`.

## Bila hendak membenam vs merujuk

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

## Reka bentuk untuk corak akses (prinsip utama)

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

## Mengapa ia penting

Reka bentuk skema adalah amat penting dalam MongoDB — ia berbeza daripada dan boleh dikatakan lebih berkesan berbanding dalam SQL, kerana model dokumen MongoDB yang fleksibel memberi anda pilihan yang ketara memberi kesan kepada prestasi dan kebolehselenggaraan, jadi memahaminya adalah penting untuk membina aplikasi MongoDB yang berkesan.

Keputusan utama — **pembenaman vs rujukan** — ialah pilihan reka bentuk MongoDB yang menentukan: **pembenaman** (menyimpan data berkaitan dalam dokumen) membolehkan bacaan satu-pertanyaan yang pantas bagi data berkaitan (tiada join) dan sesuai untuk data yang diakses bersama dan hubungan "mengandungi", manakala **rujukan** (memautkan dokumen berasingan mengikut id) sesuai untuk data besar/tidak terbatas, data yang diakses secara bebas, dan hubungan dikongsi/banyak.

Memahami **bila menggunakan setiap satu** (benam untuk data terbatas, diakses-bersama, dimiliki; rujuk untuk hubungan besar/berkembang, bebas, dikongsi, atau banyak — dan mengambil kira had saiz dokumen 16MB MongoDB) ialah kemahiran utama.

Yang paling penting, memahami prinsip panduan — **reka bentuk untuk corak akses** (susun data berdasarkan *cara anda mempertanyakannya*, supaya pertanyaan biasa cekap, selalunya satu bacaan dokumen, dan bukannya menormalkan secara lalai seperti SQL) — ialah apa yang membezakan reka bentuk skema MongoDB yang baik.

Ini mungkin bermakna menerima beberapa **denormalisasi** (pertindihan) untuk kecekapan bacaan, satu imbangan terhadap kerumitan kemas kini yang boleh diterima dan selalunya betul dalam MongoDB.

Memandangkan reka bentuk skema memberi kesan mendalam kepada prestasi dan kebolehselenggaraan aplikasi MongoDB (pilihan benam/rujuk yang lemah menyebabkan pertanyaan perlahan, dokumen besar, atau kerumitan kemas kini), dan memandangkan pendekatan berasaskan corak-akses, benam-vs-rujuk pada dasarnya berbeza daripada normalisasi SQL, memahami reka bentuk skema MongoDB — keputusan benam/rujuk, bila menggunakan setiap satu, dan mereka bentuk untuk corak akses — ialah pengetahuan penting dan bernilai tinggi untuk membina aplikasi MongoDB yang berkesan, salah satu topik MongoDB yang paling penting dan tersendiri yang membezakan mereka yang mereka bentuk skema dokumen yang baik daripada mereka yang secara naif memindahkan reka bentuk hubungan.