@Gareth , możesz to zrobić na wiele sposobów. Kluczowym problemem jest więc to, jak planujesz wysyłać zapytania o dane (tj.:jakie zapytania muszą być szybkie )
Oto kilka metod.
Metoda nr 1:kolekcja „linki”
Możesz zbudować kolekcję, która po prostu zawiera mapowania między kolekcjami.
Zalety:
- Obsługuje atomowe aktualizacje, dzięki czemu dane nie zostaną utracone
Wady:
- Dodatkowe zapytanie podczas próby poruszania się między kolekcjami
Metoda nr 2:przechowuj kopie mniejszych mapowań w większej kolekcji
Na przykład:masz miliony Products , ale tylko sto Categories . Następnie zachowałbyś Categories jako tablica wewnątrz każdego Product .
Zalety:
- Najmniejszy ślad
- Potrzebujesz tylko jednej aktualizacji
Wady:
- Dodatkowe zapytanie, jeśli pójdziesz „złą drogą”
Metoda nr 3:przechowuj kopie wszystkich mapowań w obu kolekcjach
(co sugerujesz)
Zalety:
- Dostęp do pojedynczego zapytania, aby poruszać się między kolekcjami
Wady:
- Potencjalnie duże indeksy
- Wymaga transakcji (?)
Porozmawiajmy o „potrzebach transakcji”. Istnieje kilka sposobów przeprowadzania transakcji i naprawdę zależy to od wymaganego rodzaju bezpieczeństwa.
Zdecydowanie możesz to zrobić. Musisz zadać sobie pytanie, co najgorszego może się wydarzyć, jeśli tylko jeden z zapisów się nie powiedzie?
Sposób 4:kolejkowanie zmiany
Nie wiem, czy kiedykolwiek pracowałeś z kolejkami, ale jeśli masz trochę swobody, możesz zbudować prostą kolejkę i mieć różne zadania, które aktualizują swoje kolekcje.
To znacznie bardziej zaawansowane rozwiązanie. Zdecydowałbym się na #2 lub #3.
