Tergantung.
Itu tergantung pada berapa banyak dari masing-masing jenis objek yang Anda harapkan. Bisakah Anda memasukkan semuanya ke dalam satu dokumen MongoDB untuk Pengguna tertentu? Mungkin tidak.
Itu tergantung pada hubungan - apakah akun pengguna adalah hubungan satu-ke-banyak atau banyak-ke-banyak? Jika satu ke banyak dan jumlah Akun kecil, Anda dapat memilih untuk memasukkannya ke dalam IList pada dokumen Pengguna.
Anda masih dapat memodelkan hubungan di MongoDB dengan koleksi terpisah TETAPI tidak ada gabungan dalam database sehingga Anda harus melakukannya dalam kode. Memuat Pengguna dan kemudian memuat Akun mereka mungkin baik-baik saja dari perspektif kinerja.
Anda dapat mengindeks array INTO pada dokumen. Jangan menganggap Indeks hanya sebagai indeks pada bidang sederhana pada dokumen (seperti SQL). Anda dapat menggunakan, katakanlah, koleksi Tag pada dokumen dan mengindeks ke dalam tag. (Lihat http://www.mongodb.org/display/DOCS/Indexes #Indexes-Arrays )
Saat Anda mengambil atau menulis data, Anda dapat melakukan pembacaan sebagian dan penulisan sebagian pada dokumen apa pun. (lihat http://www.mongodb.org/display /DOCS/Retrieving+a+Subset+of+Fields )
Dan, akhirnya, ketika Anda tidak dapat melihat cara mendapatkan apa yang Anda inginkan menggunakan koleksi dan indeks, Anda mungkin dapat mencapainya menggunakan pengurangan peta. Misalnya, untuk menemukan semua tag yang sedang digunakan diurutkan berdasarkan frekuensi penggunaannya, Anda akan memetakan setiap dokumen memancarkan tag yang digunakan di dalamnya, dan kemudian Anda akan mengurangi yang diatur untuk mendapatkan hasil yang Anda inginkan. Anda kemudian dapat menyimpan hasil pengurangan peta tersebut secara permanen dan hanya memperbaruinya jika diperlukan.
Satu kekhawatiran lebih lanjut:Anda menyebutkan menghitung total berdasarkan tag. Jika Anda menginginkan konsistensi transaksional berkualitas akuntansi, MongoDB mungkin bukan pilihan yang tepat untuk Anda. "Konsistensi akhirnya" adalah nama permainan untuk penyimpanan data NoSQL dan umumnya tidak cocok untuk transaksi keuangan. Misalnya, tidak masalah jika satu pengguna melihat posting blog dengan 3 komentar sementara yang lain melihat 4 karena mereka menemukan salinan replika berbeda yang belum sinkron, tetapi untuk laporan keuangan, konsistensi semacam itu penting - Anda laporan mungkin tidak bertambah!
