Bagaimana Anda merancang skema dalam MongoDB?

Question

Accepted Answer

Desain skema MongoDB berpusat pada keputusan utama: **embedding** (menyimpan data terkait di dalam dokumen) vs **referencing** (menyimpan data terkait di dokumen/koleksi terpisah dengan referensi). Tidak seperti normalisasi default SQL, desain MongoDB dioptimalkan untuk cara data *diakses*.

## Embedding — simpan data terkait 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)
```

**Embedding** menyimpan data terkait dalam satu dokumen — bacanya semua dalam satu kueri (cepat, tidak ada joins). Bagus untuk data yang diakses bersama-sama dan hubungan "contains".

## Referencing — hubungkan dokumen terpisah

```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** menyimpan data secara terpisah dan menghubungkan dengan id (seperti foreign key) — kueri secara terpisah atau join dengan `$lookup`.

## Kapan menggunakan 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)
```

## Merancang untuk access patterns (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 ini penting

Desain skema sangat penting dalam MongoDB — berbeda dari dan mungkin lebih berdampak dibanding SQL, karena model dokumen fleksibel MongoDB memberi Anda pilihan yang secara signifikan mempengaruhi performa dan kemudahan pemeliharaan, jadi memahaminya sangat penting untuk membangun aplikasi MongoDB yang efektif.

Keputusan utama — **embedding vs referencing** — adalah pilihan desain MongoDB yang mendefinisikan: **embedding** (menyimpan data terkait dalam dokumen) memungkinkan pembacaan kueri tunggal yang cepat dari data terkait (tidak ada joins) dan cocok untuk data yang diakses bersama-sama dan hubungan "contains", sementara **referencing** (menghubungkan dokumen terpisah dengan id) cocok untuk data besar/tidak terbatas, data yang diakses secara independen, dan hubungan berbagi/many.

Memahami **kapan menggunakan masing-masing** (embed untuk data terbatas, diakses bersama, dimiliki; reference untuk data besar/berkembang, independen, berbagi, atau many — dan waspada terhadap batas ukuran dokumen MongoDB 16MB) adalah keterampilan utama.

Paling penting, memahami prinsip panduan — **merancang untuk access patterns** (struktur data di sekitar *cara Anda menanyakannya*, sehingga kueri umum efisien, sering kali pembacaan dokumen tunggal, daripada normalisasi default seperti SQL) — adalah yang membedakan desain skema MongoDB yang baik.

Ini mungkin berarti menerima beberapa **denormalisasi** (duplikasi) untuk efisiensi baca, trade-off terhadap kompleksitas update yang dapat diterima dan sering kali benar dalam MongoDB.

Karena desain skema sangat mempengaruhi performa dan kemudahan pemeliharaan aplikasi MongoDB (pilihan embed/reference yang buruk menyebabkan kueri lambat, dokumen besar, atau kompleksitas update), dan karena pendekatan berbasis access-pattern, embed-vs-reference secara fundamental berbeda dari normalisasi SQL, memahami desain skema MongoDB — keputusan embed/reference, kapan menggunakan masing-masing, dan merancang untuk access patterns — sangat penting dan pengetahuan bernilai tinggi untuk membangun aplikasi MongoDB yang efektif, salah satu topik MongoDB paling penting dan khas yang membedakan mereka yang merancang skema dokumen baik dari mereka yang naif mengalihkan desain relasional.