Berdasarkan informasi yang Anda berikan, saya akan merekomendasikan dua pendekatan yang mungkin, mulai dari dasar yang sama:
Saya akan merekomendasikan pendekatan ini jika:
- Anda memiliki kardinalitas tinggi dari kedua dokumen artikel, serta platform
-
Anda ingin dapat mengelola kedua entitas secara independen, sekaligus menyinkronkan referensi di antara keduanya
// articles collection schema { "_id": ..., "title": "I am an article", ... "platforms": [ "platform_1", "platform_2", "platform_3" ], ... } // platforms collection schema { "_id": "platform_1", "name": "Platform 1", "url": "http://right/here", ... }, { "_id": "platform_2", "name": "Platform 2", "url": "http://right/here", ... }, { "_id": "platform_3", "name": "Platform 3", "url": "http://right/here", ... }
Meskipun pendekatan ini cukup fleksibel, ada biayanya - jika Anda memerlukan data artikel dan platform, Anda harus mengaktifkan lebih banyak kueri ke instans MongoDB Anda, karena data dibagi menjadi dua kumpulan yang berbeda.
Misalnya, saat memuat halaman artikel, mengingat Anda juga ingin menampilkan daftar platforms , Anda harus menjalankan kueri ke articles collection , lalu juga memicu penelusuran di platforms collection untuk mengambil semua entitas platform tempat artikel tersebut diterbitkan melalui anggota platforms s pada article document .
Namun, jika Anda hanya memiliki sebagian kecil dari platform attributes yang sering diakses yang harus tersedia saat memuat article document , Anda dapat meningkatkan platforms array pada articles collection untuk menyimpan atribut tersebut selain _id referensi ke dokumen platform:
// enhanced articles collection schema
{
"_id": ...,
"title": "I am an article",
...
"platforms": [
{platform_id: "platform_1", name: "Platform 1"},
{platform_id: "platform_2", name: "Platform 2"},
{platform_id: "platform_3", name: "Platform 3"}
],
...
}
Pendekatan hibrida ini akan cocok jika platform data attributes yang sering Anda ambil untuk ditampilkan bersama dengan data khusus artikel tidak sering berubah.
Jika tidak, Anda harus menyinkronkan semua pembaruan yang dibuat pada platform document attributes di platforms collection dengan subset atribut yang Anda lacak sebagai bagian dari larik platform untuk dokumen artikel.
Mengenai pengelolaan daftar artikel untuk platform individual, saya tidak akan merekomendasikan menyimpan referensi N-ke-N di kedua koleksi, karena mekanisme yang disebutkan di atas sudah memungkinkan Anda untuk mengekstrak daftar artikel dengan menanyakan articles collection menggunakan kueri pencarian dengan _id nilai platform document :
Approach #1
db.articles.find({"platforms": "platform_1"});
Approach #2:
db.articles.find({"platforms.platform_id": "platform_1"});
Setelah mempresentasikan dua pendekatan yang berbeda, apa yang saya sarankan sekarang adalah Anda menganalisis pola kueri dan ambang batas kinerja aplikasi Anda dan membuat keputusan yang diperhitungkan berdasarkan skenario yang Anda hadapi.
