Memilih Data Model

Tiga belas chapter di belakang kita memperkenalkan prinsip, tiga bentuk relasi, dan sembilan pola desain. Chapter penutup ini tidak menambah konsep baru — tugasnya menyusun semuanya menjadi kerangka keputusan yang bisa dipakai berulang: dari pola akses menuju skema, lewat empat lensa yang selalu kita pakai secara diam-diam. Kita akhiri dengan satu skema utuh toko buku yang menggabungkan keputusan-keputusan dari seluruh Section ini.

Empat Lensa Keputusan #

Setiap keputusan pemodelan di Section ini bisa ditelusuri ke empat lensa berikut:

1. Pola akses — query utama apa saja, rasio baca-tulisnya, data mana yang selalu diambil bersama. Lensa ini yang menentukan arah embed vs referensi.
2. Growth — apakah jumlah data terbatas atau tumbuh tanpa batas, dan seberapa cepat. Lensa ini menjaga kita dari array yang menabrak 16 MB.
3. Konsistensi — seberapa cepat duplikasi harus menyusul sumbernya, dan seberapa besar toleransi data basang. Lensa ini menentukan boleh-tidaknya duplikasi dan strategi sinkronisasinya.
4. Kompleksitas query dan aplikasi — berapa banyak query per halaman, perlu $lookup atau tidak, dan cabang kode apa yang muncul di aplikasi. Lensa ini menjaga kesederhanaan tetap jadi prioritas.

Urutan lensanya pun penting: mulai dari pola akses (apa yang aplikasi butuhkan), lalu timbangkan lensa berikutnya seperlunya. Desain yang berangkat dari bentuk data — bukan dari pertanyaan aplikasi — hampir selalu berakhir normalisasi buta.

Alur Keputusan #

Empat lensa itu bisa digulirkan menjadi alur sederhana untuk relasi apa pun:

Alur ini adalah rangkuman mekanis dari pembahasan yang panjang: pertanyaan pertama memetakan wilayah embed–referensi, pertanyaan kedua menagih kepemilikan data, pertanyaan ketiga mendeteksi gejala Subset Pattern, dan pertanyaan terakhir menguji peluang Computed Pattern. Ekor panjang yang ekstrem tetap ditangani Outlier Pattern sebagai pengecualian yang ditandai bendera, bukan cabang alur.

Tabel Skenario ke Rekomendasi #

Checklist Sebelum Menyimpan Skema #

Sebelum skema dinyatakan selesai, verifikasi cepat berikut layak dijalankan:

• Setiap halaman utama terlayani oleh jumlah query yang masuk akal — idealnya satu per document utama.
• Tidak ada array yang tumbuh tanpa batas; yang mendekati batas sudah dijepit $slice atau dipindah collection terpisah.
• Setiap field duplikat punya strategi sinkronisasi yang tertulis (update eksplisit, transaksi, atau change streams).
• Setiap field computed punya jadwal penghitungan ulang — event-driven, batch, atau keduanya.
• Arah referensi konsisten satu sumber kebenaran, kecuali dua arah benar-benar terukur diperlukan.
• Index menempel pada jalur query utama, termasuk { artikelId: 1, jumlahSuka: -1 } ala Subset Pattern dan { type: 1, ... } ala Polymorphic.

Satu Skema Utuh #

Kita rakit keputusan-keputusan itu menjadi document buku final: referensi + salinan nama penulis (Extended Reference), rating computed, subset ulasan teratas, dan bendera outlier:

use latihan_modeling
db.dropDatabase()
db.penulis.insertMany([
  { _id: 1, nama: "Tere Liye", kota: "Jakarta" },
  { _id: 2, nama: "James Clear", kota: "Ohio" }
])
db.buku.insertMany([
  {
    _id: 101, judul: "Bumi", harga: 89000,
    penulisId: 1, penulisNama: "Tere Liye",
    ratingRata: 4.5, jumlahUlasan: 2,
    ulasanTeratas: [ { pembaca: "Budi", bintang: 4 }, { pembaca: "Siti", bintang: 5 } ],
    isOutlier: false
  },
  {
    _id: 103, judul: "Atomic Habits", harga: 115000,
    penulisId: 2, penulisNama: "James Clear",
    ratingRata: 4.8, jumlahUlasan: 250000,
    isOutlier: true
  }
])

Output yang Dihasilkan:

switched to db latihan_modeling
{ ok: 1, dropped: 'latihan_modeling' }
{ acknowledged: true, insertedIds: { '0': 1, '1': 2 } }
{ acknowledged: true, insertedIds: { '0': 101, '1': 103 } }

Halaman produk untuk buku normal terlayani satu query — persis tujuan seluruh keputusan tadi:

db.buku.findOne({ _id: 101 }, { judul: 1, harga: 1, penulisNama: 1, ratingRata: 1, jumlahUlasan: 1, ulasanTeratas: 1 })

Output yang Dihasilkan:

{
  _id: 101,
  judul: 'Bumi',
  harga: 89000,
  penulisNama: 'Tere Liye',
  ratingRata: 4.5,
  jumlahUlasan: 2,
  ulasanTeratas: [ { pembaca: 'Budi', bintang: 4 }, { pembaca: 'Siti', bintang: 5 } ]
}

Sedangkan buku berbendera isOutlier ditangani jalurnya sendiri — ulasan lengkapnya dicari di collection terpisah, dan document induknya tetap ramping:

db.buku.findOne({ _id: 103 }, { judul: 1, ratingRata: 1, jumlahUlasan: 1, isOutlier: 1 })
bsonsize(db.buku.findOne({ _id: 101 }))
db.dropDatabase()

Output yang Dihasilkan:

{
  _id: 103,
  judul: 'Atomic Habits',
  ratingRata: 4.8,
  jumlahUlasan: 250000,
  isOutlier: true
}
231
{ ok: 1, dropped: 'latihan_modeling' }

Dua ratus lima puluh ribu ulasan tersimpan di tempat lain, bsonsize document buku normal tetap tiga digit byte, dan halaman mana pun tetap satu query. Itulah hasil akhir kerangka ini: bukan skema yang paling murni, melainkan skema yang paling cocok dengan pola akses aplikasinya.

Rangkuman #

• Empat lensa keputusan — pola akses, growth, konsistensi, kompleksitas — menilai setiap pilihan embed, referensi, dan pola desain.
• Alur keputusan sederhana memetakan data baru dari pertanyaan kepemilikan dan pertumbuhan menuju embed, referensi, subset, atau computed.
• Tabel skenario ke rekomendasi menghubungkan situasi nyata dengan bab pembahasannya.
• Skema final toko buku menggabungkan referensi + Extended Reference + Computed + Subset + Outlier dalam satu document yang tetap ramping.

Data modeling di MongoDB berakhir di tempat yang sama dengan awalnya: kenali pola akses aplikasi Anda, lalu biarkan document mengikuti. Section berikutnya membawa skema ini ke medan yang lebih teknis — index dan performa query.