@Gareth , du har flere legitime måder at gøre dette på. Så den vigtigste bekymring er, hvordan du planlægger at forespørge efter dataene (dvs.:hvilke forespørgsler skal være hurtige )
Her er et par metoder.
Metode #1:samlingen "links"
Du kan bygge en samling, der blot indeholder tilknytninger mellem samlingerne.
Fordele:
- Understøtter atomopdateringer, så data ikke går tabt
Udemper:
- Ekstra forespørgsel ved forsøg på at flytte mellem samlinger
Metode #2:Gem kopier af mindre kortlægninger i større samling
For eksempel:du har millioner af Products , men kun hundrede Categories . Så ville du gemme Categories som et array inde i hvert Product .
Fordele:
- Det mindste fodaftryk
- Kun brug for én opdatering
Udemper:
- Ekstra forespørgsel, hvis du går den "forkerte vej"
Metode #3:Gem kopier af alle kortlægninger i begge samlinger
(det du foreslår)
Fordele:
- Enkelt forespørgselsadgang for at flytte mellem begge samlinger
Udemper:
- Potentielt store indekser
- Har brug for transaktioner (?)
Lad os tale om "behovstransaktioner". Der er flere måder at udføre transaktioner på, og det afhænger virkelig af, hvilken type sikkerhed du har brug for.
Du kan helt sikkert gøre dette. Du bliver nødt til at spørge dig selv, hvad er det værste, der sker, hvis kun én af redningerne mislykkes?
Metode #4:Sæt ændringen i kø
Jeg ved ikke, om du nogensinde har arbejdet med køer, men hvis du har lidt spillerum, kan du bygge en simpel kø og have forskellige jobs, der opdaterer deres respektive samlinger.
Dette er en meget mere avanceret løsning. Jeg ville have en tendens til at gå med #2 eller #3.