Seorang user dapat memiliki banyak projects (dan proyek dikaitkan dengan satu pengguna saja). Ini adalah satu-ke-banyak hubungan.
Setiap user harus menyimpan daftar projects-nya . Misalnya:
user:
id: <some value>,
name: <some value>,
email: <some value>,
projects: [
{ projectId: <some value>, projectName: <...>, projectDescription: <....>, otherInfo: { fld1: <...>, fld2: <...>, etc. } },
{ projectId: <some value>, projectName: <...>, projectDescription: <....>, otherInfo: { fld1: <...>, fld2: <...>, etc. } },
...
]
Perhatikan bahwa setiap projects adalah sub-dokumen (objek atau dokumen yang disematkan) di dalam projects Himpunan. Sebuah projects memiliki detail terkait seperti, projectId , projectName , dll..
Menurut saya, seharusnya hanya ada satu koleksi disebut sebagai user_projects . Dengan asumsi bahwa:(i) seorang user mungkin memiliki 0 hingga 100 proyek, dan (ii) projects detailnya tidak terlalu besar.
Ini adalah model penyematan sisi 'banyak' dari hubungan 1-ke-N ke dalam sisi 'satu'. Ini cara yang disarankan, de-normalisasi data. Ini memiliki keuntungan dari kueri yang efisien dan cepat. Ini menyederhanakan transaksi, karena penulisan (menyisipkan, memperbarui, dan menghapus) akan menjadi atomik dengan operasi tunggal ke dokumen dalam koleksi yang sama.
Anda akan menggunakan user id atau name (dengan indeks unik) untuk mengambil dokumen, dan itu akan menjadi permintaan yang sangat cepat. Anda dapat memiliki indeks pada projects array (indeks pada bidang array disebut sebagai Indeks Multikey ) - di bidang proyek. Misalnya, indeks pada projectId atau/dan projectName masuk akal.
Anda bisa mendapatkan semua proyek untuk pengguna - ini adalah kueri sederhana menggunakan user id / name . Permintaan proyeksi memungkinkan informasi apa yang terkait dengan projects ditampilkan. Anda dapat menggunakan find atau aggregate metode untuk membuat kueri. Anda dapat membuat kueri projects tertentu untuk user , menggunakan projectId atau projectName . Karena ada indeks pada user dan projects bidang, ini akan menjadi kueri yang efisien.
Jadi, rekomendasi saya adalah memiliki satu koleksi, user_projects , dengan user informasi dan projects informasi yang tertanam di dalamnya.
