Baserat på informationen som du lämnade skulle jag rekommendera två möjliga tillvägagångssätt, utgående från samma grund:
Jag skulle rekommendera detta tillvägagångssätt om:
- Du har en hög kardinalitet för både artikeldokument och plattformar
-
Du vill kunna hantera båda enheterna oberoende av varandra, samtidigt som du synkroniserar referenser mellan dem
// 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", ... }
Även om det här tillvägagångssättet är ganska flexibelt, kommer det till en kostnad - om du behöver både artikel- och plattformsdata måste du skicka fler frågor till din MongoDB-instans, eftersom informationen är uppdelad i två olika samlingar.
Till exempel, när du laddar en artikelsida, med tanke på att du också vill visa en lista över platforms , måste du skicka en fråga till articles collection , och sedan även utlösa en sökning på platforms collection för att hämta alla plattformsenheter till vilka artikeln publiceras via medlemmarna av platform s array på article document .
Men om du bara har en liten delmängd av platform attributes som du måste ha tillgänglig när du laddar ett article document , kan du förbättra platforms array i articles collection för att lagra dessa attribut utöver _id referens till plattformsdokumenten:
// 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"}
],
...
}
Denna hybridmetod skulle vara lämplig om platform data attributes som du ofta hämtar för att visa tillsammans med artikelspecifika data ändras inte så ofta.
Annars måste du synkronisera alla uppdateringar som görs av platform document attributes i platforms collection med underuppsättningen av attribut som du spårar som en del av plattformsarrayen för artikeldokument.
När det gäller hanteringen av artikellistor för enskilda plattformar, skulle jag inte rekommendera att lagra N-till-N-referenser i båda samlingarna, eftersom den tidigare nämnda mekanismen redan tillåter dig att extrahera artikellistor genom att fråga articles collection med hjälp av en sökfråga med _id värdet för platform document :
Approach #1
db.articles.find({"platforms": "platform_1"});
Approach #2:
db.articles.find({"platforms.platform_id": "platform_1"});
Efter att ha presenterat två olika tillvägagångssätt, vad jag skulle rekommendera nu är att du analyserar frågemönster och prestandatrösklar för din applikation och fattar ett beräknat beslut baserat på de scenarier som du stöter på.