Na základě informací, které jste poskytli, bych doporučil dva možné přístupy, vycházející ze stejného základu:
Tento přístup bych doporučil, pokud:
- Máte vysokou mohutnost jak dokumentů článků, tak platforem
-
Chcete mít možnost spravovat obě entity nezávisle a zároveň mezi nimi synchronizovat reference
// 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", ... }
I když je tento přístup poměrně flexibilní, něco stojí – pokud požadujete jak data článku, tak data platformy, budete muset na svou instanci MongoDB zadávat více dotazů, protože data jsou rozdělena do dvou různých kolekcí.
Například při načítání stránky s článkem, uvážíte-li, že chcete také zobrazit seznam platforms , budete muset spustit dotaz na articles collection a poté také spustit vyhledávání v platforms collection k načtení všech entit platformy, na kterých je tento článek publikován, prostřednictvím členů platform s pole v article document .
Pokud však máte pouze malou podmnožinu často používaných platform attributes který potřebujete mít k dispozici při načítání article document , můžete vylepšit platform pole v articles collection k uložení těchto atributů kromě _id odkaz na dokumenty platformy:
// 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"}
],
...
}
Tento hybridní přístup by byl vhodný, pokud by platform data attributes které často načítáte a zobrazujete spolu s údaji specifickými pro článek, se tak často nemění.
V opačném případě budete muset synchronizovat všechny aktualizace provedené v platform document attributes v platforms collection s podmnožinou atributů, které sledujete jako součást pole platforem pro články s články.
Pokud jde o správu seznamů článků pro jednotlivé platformy, nedoporučoval bych ukládat reference N-to-N v obou kolekcích, protože výše zmíněný mechanismus již umožňuje extrahovat seznamy článků dotazem na articles collection pomocí vyhledávacího dotazu s _id hodnotu platform document :
Approach #1
db.articles.find({"platforms": "platform_1"});
Approach #2:
db.articles.find({"platforms.platform_id": "platform_1"});
Po předložení dvou různých přístupů bych vám nyní doporučil analyzovat vzory dotazů a prahové hodnoty výkonu vaší aplikace a učinit vypočítané rozhodnutí na základě scénářů, se kterými se setkáte.