Contoh yang Anda berikan, sama dengan kebanyakan contoh dunia nyata dari hubungan banyak-ke-banyak, sebenarnya adalah contoh sedikit-ke-sedikit hubungan. Anda mungkin memiliki banyak restoran dan banyak pengunjung tetapi, dibandingkan dengan seluruh rangkaian, setiap restoran tertentu hanya melayani sebagian kecil pengunjung dan sebagian besar pengunjung individu hanya akan mengunjungi sebagian kecil restoran. Kedengarannya seperti jaringan yang jarang terhubung dengan rasio kepadatan tautan jauh di bawah satu.
Namun, Anda bertanya tentang banyak-ke-banyak jadi bagaimana kalau kita menggunakan jaringan saraf sebagai contoh? Jaringan saraf sering membentuk jaringan padat dan mewakili jaringan banyak-ke-banyak yang sebenarnya. Dalam hal ini jawabannya mudah - jangan gunakan mongoDB. Gunakan struktur khusus dan strategi serialisasi yang disesuaikan dengan kebutuhan spesifik Anda. Lagi pula, hubungan banyak-ke-banyak yang sebenarnya hampir selalu merupakan hal yang berbeda sehingga membenarkan perlakuan khusus.
Karena itu, membuat model sedikit-ke-sedikit yang lebih biasa hubungan di mongoDB dapat dicapai tanpa mengorbankan struktur dokumen yang kaya, dan cara Anda mencapainya bergantung pada pola akses Anda.
Jadi, dengan contoh jaringan restoran / restoran, jika Anda biasanya akan menanyakan restoran tentang pengunjungnya, maka Anda akan membuat array diner_ids yang diadakan di setiap restoran. Cara lain akan berarti sebuah array restaurant_ids diadakan dengan masing-masing restoran. Keduanya untuk kemampuan query dua arah.
Perhatian harus diberikan karena tidak ada batasan foreign_key di mongoDB dan oleh karena itu menjaga integritas referensial data Anda adalah tanggung jawab Anda.
Jika kinerja paling penting bagi Anda, maka Anda mungkin ingin menyematkan data di setiap dokumen daripada merujuknya dengan id. Ini adalah opsi kinerja yang lebih tinggi untuk membaca (tidak terlalu banyak untuk menulis) karena semua data dapat diambil dari disk dalam satu pukulan. Ini berarti Anda perlu melakukan lebih banyak pekerjaan saat memperbarui nilai data untuk memastikan integritas data Anda, tetapi seringkali ini tidak seseram yang terlihat pertama kali. Seberapa sering pengunjung benar-benar mengubah nama mereka? Dan tergantung pada ukuran dokumen, Anda mungkin tidak perlu menyematkan dokumen lengkap, subset data ditambah id untuk menunjuk ke catatan lengkap akan sering berhasil.
Singkatnya, desain skema mongoDB harus didorong oleh persyaratan aplikasi. Skema yang berbeda untuk aplikasi yang berbeda sebagai lawan dari satu DB relasional monolitik untuk mengatur semuanya. Bagaimana realitas datanya? Bagaimana sebenarnya aplikasi menggunakan data ini? Seberapa besar objek dokumen yang disimpan? Jawab pertanyaan ini dan skema Anda akan mendesain sendiri secara praktis.
