MongoDB dan Database Relasional

Jika kita pernah membangun aplikasi di atas MySQL atau PostgreSQL, cara berpikir kita sudah terlatih memandang data sebagai tabel, baris, dan kolom. Pindah ke MongoDB menjadi jauh lebih mudah bila kita memetakan istilah lama ke istilah baru secara sadar — sekaligus memahami di mana persamaan itu berhenti. Chapter ini membandingkan kedua dunia secara jujur, termasuk soal index yang sering disalahpahami.

Materinya mencakup peta istilah, filosofi skema, penanganan relasi antar data, dan batas perbandingan pada transaksi serta join berat.

Peta Istilah Relasional ke MongoDB #

Tabel ini adalah peta awal, bukan persamaan sempurna. Dua perbedaan filosofis di bagian berikutnya jauh lebih penting daripada hafalan istilah.

Skema Kaku vs Skema Fleksibel #

Database relasional menerapkan skema saat menulis (schema-on-write): struktur kolom dan tipenya dideklarasikan lewat CREATE TABLE, dan baris yang tidak sesuai bentuk tersebut akan ditolak. MongoDB menerapkan skema saat membaca (schema-on-read): collection menerima document dengan bentuk apa pun, dan konsistensi bentuk dijaga oleh kode aplikasi. Bila butuh aturan tegas, MongoDB menyediakan validator berbasis JSON Schema pada collection.

Contoh berikut memperlihatkan dua document dalam satu collection buku dengan bentuk yang berbeda:

// mdtest: skip
// Document dengan ISBN
{
  _id: ObjectId("5f1a2b3c4d5e6f7a8b9c0d1e"),
  judul: "Belajar MongoDB",
  isbn: "978-1-2345-6789-0",
  halaman: 240
}

// Document tanpa ISBN, dengan field tambahan
{
  _id: ObjectId("5f1a2b3c4d5e6f7a8b9c0d1f"),
  judul: "Catatan Kuliah",
  halaman: 88,
  topik: ["database", "nosql"]
}

Document pertama memiliki field isbn dan document kedua tidak — keduanya tetap sah di collection yang sama. Di dunia relasional, variasi seperti ini menuntut kolom nullable, tabel terpisah, atau desain EAV; di MongoDB variasi tersebut adalah kondisi normal.

Relasi Data: Join, Embedding, dan Referencing #

Database relasional menormalkan data ke tabel-tabel kecil, lalu merangkainya kembali dengan JOIN saat query. MongoDB menawarkan dua pola untuk relasi antar data:

Diagram di atas memperlihatkan kedua pola. Pola embedding menyimpan data terkait langsung di dalam document induk, seperti contoh pesanan berikut:

// mdtest: skip
{
  _id: ObjectId("6a1f0c9b7e3d4f5a6b7c8d90"),
  nomorPesanan: "INV-2026-0042",
  pelanggan: "[email protected]",
  items: [
    { productId: ObjectId("6a1f0c9b7e3d4f5a6b7c8d01"),
      nama: "Kopi Gayo 250g", qty: 2, hargaSaatBeli: 85000 },
    { productId: ObjectId("6a1f0c9b7e3d4f5a6b7c8d02"),
      nama: "Filter Paper", qty: 1, hargaSaatBeli: 15000 }
  ],
  total: 185000
}

Satu kali pembacaan document pesanan sekaligus membawa seluruh isinya — tidak ada join yang perlu dirangkai. Pola referencing menyimpan _id tujuan, lalu menggabungkan datanya saat query menggunakan $lookup:

// mdtest: skip
db.pesanan.aggregate([
  {
    $lookup: {
      from: "produk",
      localField: "productId",
      foreignField: "_id",
      as: "produk"
    }
  }
])

Aturan praktisnya: data yang selalu dibaca bersama induknya dan jarang berubah cocok di-embed; data yang dipakai banyak document atau sering berubah lebih aman di-reference. Trade-off ini kita bedah menyeluruh di section pemodelan data.

Soal Index: Kedua Dunia Sama-Sama Memakai B-tree #

Ada asumsi keliru yang beredar lama: “NoSQL cepat karena tidak memakai index.” Faktanya kebalikannya — MongoDB memakai struktur B-tree untuk secondary index-nya, sama seperti keluarga struktur yang dipakai mayoritas database relasional (umumnya varian B+ tree). Mencari satu nilai lewat index di kedua dunia sama-sama efisien secara logaritmik; tidak ada keunggulan otomatis dari sekadar berganti kubu.

Lalu dari mana kesan “MongoDB lebih cepat” berasal? Dari model data. Embedding memindahkan data yang biasanya dirangkai lewat join ke dalam satu document, sehingga satu operasi baca bisa menggantikan beberapa join. Keunggulan itu lahir dari desain skema yang sesuai pola akses — bukan dari struktur data yang otomatis lebih cepat.

Transaksi dan Titik Batas Perbandingan #

Setiap penulisan pada satu document di MongoDB bersifat atomik — pembaca tidak akan melihat document setengah terbarui. Untuk perubahan lintas document, MongoDB menyediakan transaksi multi-document ACID sejak versi 4.0.

Namun kita perlu jujur soal batasnya. Transaksi multi-document bukan kekuatan utama MongoDB: berjalan di atas replica set, membutuhkan sesi khusus, dan berbiaya lebih tinggi dibandingkan penulisan document tunggal. Sebagai gambaran ringkas:

Kesimpulannya: apabila domain data kita benar-benar relasional — banyak entitas terpisah, normalisasi penuh, dan query yang terus-menerus merangkai banyak tabel dengan transaksi kompleks — database relasional tetap kandidat utama. Apabila data kita kaya bentuk dan pola aksesnya jelas, MongoDB memberi jalan yang lebih sederhana.

Rangkuman #

• Istilahnya terpetakan rapi — table menjadi collection, row menjadi document, column menjadi field — tetapi filosofi skemanya berbeda: relasional menegakkan saat menulis, MongoDB saat membaca.
• Relasi antar data ditangani lewat embedding (data ikut induknya) atau referencing plus $lookup (left outer join di aggregation pipeline).
• Kedua dunia sama-sama memakai keluarga struktur B-tree untuk index; keunggulan MongoDB lahir dari desain document yang cocok dengan pola akses.
• Transaksi multi-document ACID tersedia sejak MongoDB 4.0, tetapi untuk domain yang sepenuhnya relasional dengan join berat, database relasional tetap pilihan yang lebih tepat.