Anda dapat mendesain skema tempat Anda dapat mereferensikan atau menyematkan dokumen. Mari kita lihat opsi pertama dari dokumen yang disematkan. Dengan aplikasi Anda di atas, Anda dapat menyimpan informasi dalam dokumen sebagai berikut:
// db.table1 schema
{
"_id": 3, // table1_id
"is_active": true,
"created": ISODate("2015-04-07T16:00:30.798Z"),
"lang": [
{
"name": "foo",
"surname": "bar",
"address": "xxx"
},
{
"name": "abc",
"surname": "def",
"address": "xyz"
}
]
}
Dalam contoh skema di atas, pada dasarnya Anda akan menyematkan table1_lang informasi dalam table1 utama dokumen. Desain ini memiliki kelebihan, salah satunya adalah lokalitas data. Karena MongoDB menyimpan data secara berurutan pada disk, meletakkan semua data yang Anda butuhkan dalam satu dokumen memastikan bahwa disk yang berputar akan membutuhkan lebih sedikit waktu untuk mencari lokasi tertentu pada disk. Jika aplikasi Anda sering mengakses table1 informasi bersama dengan table1_lang data maka Anda hampir pasti ingin pergi ke rute yang disematkan. Keuntungan lain dengan dokumen yang disematkan adalah atomisitas dan isolasi dalam menulis data. Untuk mengilustrasikan ini, katakanlah Anda ingin menghapus dokumen yang memiliki kunci lang "nama" dengan nilai "foo", ini dapat dilakukan dengan satu operasi (atomik):
db.table.remove({"lang.name": "foo"});
Untuk detail lebih lanjut tentang pemodelan data di MongoDB, silakan baca dokumen Pengenalan Pemodelan Data , khususnya Model Hubungan Satu-ke-Banyak dengan Dokumen Tersemat
Opsi desain lainnya adalah referensi dokumen tempat Anda mengikuti skema yang dinormalisasi. Misalnya:
// db.table1 schema
{
"_id": 3
"is_active": true
"created": ISODate("2015-04-07T16:00:30.798Z")
}
// db.table1_lang schema
/*
1
*/
{
"_id": 1,
"table1_id": 3,
"name": "foo",
"surname": "bar",
"address": "xxx"
}
/*
2
*/
{
"_id": 2,
"table1_id": 3,
"name": "abc",
"surname": "def",
"address": "xyz"
}
Pendekatan di atas memberikan peningkatan fleksibilitas dalam melakukan kueri. Misalnya, untuk mengambil semua anak table1_lang dokumen untuk entitas induk utama table1 dengan id 3 akan mudah, cukup buat kueri terhadap koleksi table1_lang :
db.table1_lang.find({"table1_id": 3});
Skema normalisasi di atas menggunakan pendekatan referensi dokumen juga memiliki keuntungan ketika Anda memiliki hubungan satu-ke-banyak dengan arity yang sangat tidak terduga. Jika Anda memiliki ratusan atau ribuan table_lang dokumen per pemberian table entitas, embedding memiliki begitu banyak kemunduran sejauh menyangkut batasan spasial karena semakin besar dokumen, semakin banyak RAM yang digunakan dan dokumen MongoDB memiliki batas ukuran keras 16MB.
Aturan umumnya adalah jika pola kueri aplikasi Anda sudah dikenal dan data cenderung diakses hanya dengan satu cara, pendekatan tersemat akan berfungsi dengan baik. Jika aplikasi Anda menanyakan data dalam banyak cara atau Anda tidak dapat mengantisipasi pola kueri data, model referensi dokumen yang lebih dinormalisasi akan sesuai untuk kasus tersebut.
Referensi:
