@Гарет , имате няколко законни начина да направите това. Така че тяхната основна грижа е как планирате да правите заявки за данните (т.е.:какви заявки трябва да бъдат бързи )
Ето няколко метода.
Метод №1:колекцията „връзки“
Можете да създадете колекция, която просто съдържа съпоставяния между колекциите.
Плюсове:
- Поддържа атомарни актуализации, така че данните да не се губят
Недостатъци:
- Допълнителна заявка при опит за придвижване между колекции
Метод №2:съхранявайте копия на по-малки съпоставяния в по-голяма колекция
Например:имате милиони Products , но само сто Categories . Тогава ще съхраните Categories като масив във всеки Product .
Плюсове:
- Най-малък отпечатък
- Необходима е само една актуализация
Недостатъци:
- Допълнително запитване, ако тръгнете по „грешния път“
Метод #3:съхранявайте копия на всички съпоставяния в двете колекции
(какво предлагате)
Плюсове:
- Достъп до една заявка за придвижване между двете колекции
Недостатъци:
- Потенциално големи индекси
- Необходими са транзакции (?)
Нека поговорим за „транзакции за нужди“. Има няколко начина за извършване на транзакции и наистина зависи от това какъв тип безопасност имате нужда.
Определено можете да направите това. Ще трябва да се запитате какво е най-лошото, което се случва, ако само едно от спасяванията е неуспешно?
Метод #4:поставете промяната в опашка
Не знам дали някога сте работили с опашки, но ако имате известна свобода на действие, можете да създадете проста опашка и да имате различни задачи, които актуализират съответните си колекции.
Това е много по-модерно решение. Бих предпочел №2 или №3.
