Na podstawie podanych przez Ciebie informacji polecam dwa możliwe podejścia, zaczynając od tej samej podstawy:
Polecam to podejście, jeśli:
- Masz wysoką kardynalność zarówno dokumentów artykułów, jak i platform
-
Chcesz mieć możliwość niezależnego zarządzania obydwoma jednostkami, a także synchronizowania między nimi referencji
// 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", ... }
Nawet jeśli to podejście jest dość elastyczne, wiąże się to z pewnymi kosztami – jeśli potrzebujesz zarówno danych artykułów, jak i danych platformy, będziesz musiał uruchomić więcej zapytań do swojej instancji MongoDB, ponieważ dane są podzielone na dwie różne kolekcje.
Na przykład podczas ładowania strony artykułu, biorąc pod uwagę, że chcesz również wyświetlić listę platforms , musiałbyś uruchomić zapytanie do articles collection , a następnie uruchomić wyszukiwanie w platforms collection aby pobrać wszystkie encje platformy, na których ten artykuł jest publikowany za pośrednictwem członków platform s tablicy w article document .
Jeśli jednak masz tylko mały podzbiór często używanych platform attributes które musisz mieć dostępne podczas ładowania article document , możesz ulepszyć platform tablica w articles collection do przechowywania tych atrybutów oprócz _id odniesienie do dokumentów 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"}
],
...
}
To hybrydowe podejście byłoby odpowiednie, jeśli platform data attributes które często pobierasz do wyświetlenia wraz z danymi specyficznymi dla artykułu, nie zmieniają się tak często.
W przeciwnym razie będziesz musiał zsynchronizować wszystkie aktualizacje dokonane w platform document attributes w platforms collection z podzbiorem atrybutów, które śledzisz jako część tablicy platform dla dokumentów artykułów.
Jeśli chodzi o zarządzanie listami artykułów dla poszczególnych platform, nie zalecałbym przechowywania odniesień N-do-N w obu kolekcjach, ponieważ wspomniany mechanizm pozwala już wyodrębnić listy artykułów przez zapytanie articles collection za pomocą zapytania wyszukiwania z _id wartość platform document :
Approach #1
db.articles.find({"platforms": "platform_1"});
Approach #2:
db.articles.find({"platforms.platform_id": "platform_1"});
Po przedstawieniu dwóch różnych podejść polecam teraz przeanalizowanie wzorców zapytań i progów wydajności aplikacji oraz podjęcie obliczonej decyzji na podstawie napotkanych scenariuszy.
