user może mieć wiele projects (a projekt jest powiązany tylko z jednym użytkownikiem). To jest jeden do wielu związek.
Każdy user powinien przechowywać listę swoich projects . Na przykład:
user:
id: <some value>,
name: <some value>,
email: <some value>,
projects: [
{ projectId: <some value>, projectName: <...>, projectDescription: <....>, otherInfo: { fld1: <...>, fld2: <...>, etc. } },
{ projectId: <some value>, projectName: <...>, projectDescription: <....>, otherInfo: { fld1: <...>, fld2: <...>, etc. } },
...
]
Zwróć uwagę, że każdy project jest dokumentem podrzędnym (obiektem lub osadzonym dokumentem) w ramach projects szyk. project ma powiązane szczegóły, takie jak projectId , projectName itp.
Myślę, że powinna być tylko jedna kolekcja nazywana jako user_projects . Zakładając, że:(i) user może mieć od 0 do 100 projektów i (ii) project szczegóły nie są zbyt duże.
Jest to model osadzania strony „wielu” relacji 1 do N w stronę „jednego”. To zalecany sposób, denormalizujący dane. Ma to zaletę wydajnych i szybkich zapytań. Upraszcza to transakcje, ponieważ zapisy (wstawienia, aktualizacje i usunięcia) będą niepodzielne przy pojedynczej operacji na dokumencie w tej samej kolekcji.
Będziesz używać user id lub name (z unikalnym indeksem), aby pobrać dokument i będzie to bardzo szybkie zapytanie. Możesz mieć indeks w projects tablica (indeksy w polach tablicy są nazywane indeksami wielokluczowymi ) - na polach projektu. Na przykład indeks na projectId lub/i projectName ma sens.
Możesz pobrać wszystkie projekty dla użytkownika - to proste zapytanie za pomocą user id / name . Zapytanie projekcja zezwala na jakie informacje związane z project jest wyświetlany. Możesz użyć find lub aggregate metoda budowania zapytania.Możesz zapytać o konkretny project dla user , używając projectId lub projectName . Ponieważ istnieją indeksy dla user i project pola, będzie to skuteczne zapytanie.
Tak więc radzę mieć jedną kolekcję, user_projects , z user informacje i projects informacje w nim zawarte.
