Op basis van de informatie die u heeft verstrekt, zou ik twee mogelijke benaderingen aanbevelen, uitgaande van dezelfde basis:
Ik zou deze aanpak aanbevelen als:
- U heeft een hoge mate van kardinaliteit van zowel artikeldocumenten als platforms
-
U wilt beide entiteiten onafhankelijk kunnen beheren, terwijl u ook referenties tussen hen synchroniseert
// 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", ... }
Zelfs als deze benadering vrij flexibel is, brengt dit kosten met zich mee - als u zowel artikel- als platformgegevens nodig heeft, moet u meer query's naar uw MongoDB-instantie sturen, omdat de gegevens in twee verschillende verzamelingen zijn opgesplitst.
Als u bijvoorbeeld een artikelpagina laadt, moet u bedenken dat u ook een lijst met platforms . wilt weergeven , zou u een query moeten uitvoeren op de articles collection , en activeer vervolgens ook een zoekopdracht in de platforms collection om alle platformentiteiten op te halen waaraan dat artikel is gepubliceerd via de leden van het platform s array op het article document .
Als u echter slechts een kleine subset van vaak gebruikte platform attributes heeft die u bij de hand moet hebben bij het laden van een article document , kunt u de platforms verbeteren array op de articles collection om die attributen op te slaan naast de _id verwijzing naar de platformdocumenten:
// 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"}
],
...
}
Deze hybride benadering zou geschikt zijn als de platform data attributes die u vaak ophaalt om samen met artikelspecifieke gegevens weer te geven, veranderen niet zo vaak.
Anders moet u alle updates synchroniseren die zijn aangebracht in de platform document attributes in de platforms collection met de subset van attributen die u bijhoudt als onderdeel van de platformarray voor artikeldocumenten.
Wat betreft het beheer van artikellijsten voor afzonderlijke platforms, zou ik niet aanraden om N-to-N-referenties in beide collecties op te slaan, aangezien het bovengenoemde mechanisme u al in staat stelt om artikellijsten te extraheren door de articles collection op te vragen. een zoekopdracht gebruiken met de _id waarde van het platform document :
Approach #1
db.articles.find({"platforms": "platform_1"});
Approach #2:
db.articles.find({"platforms.platform_id": "platform_1"});
Nu ik twee verschillende benaderingen heb gepresenteerd, raad ik u nu aan om de querypatronen en prestatiedrempels van uw toepassing te analyseren en een berekende beslissing te nemen op basis van de scenario's die u tegenkomt.