user může mít mnoho projects (a projekt je spojen pouze s jedním uživatelem). Toto je jedna k mnoha vztah.
Každý user by měl uchovávat seznam svých projects . Například:
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. } },
...
]
Všimněte si, že každý project je dílčí dokument (objekt nebo vložený dokument) v rámci projects pole. project má související podrobnosti, jako je projectId , projectName , atd..
Myslím, že by měla existovat pouze jedna sbírka nazývá se user_projects . Za předpokladu, že:(i) user může mít 0 až 100 projektů a (ii) project Podrobnosti uživatele nejsou příliš velké.
Toto je model začlenění strany 'mnoho' vztahu 1-to-N do strany 'jedné'. Toto je doporučený způsob, který denormalizuje data. To má výhodu v efektivních a rychlých dotazech. To zjednodušuje transakce, protože zápisy (vkládání, aktualizace a mazání) budou atomické s jedinou operací s dokumentem ve stejné kolekci.
Budete používat user id nebo name (s jedinečným indexem) k načtení dokumentu a bude to velmi rychlý dotaz. Můžete mít index na projects pole (indexy v polích pole se nazývají Multikey indexy ) - na polích projektu. Například index na projectId nebo/a projectName dává smysl.
Můžete získat všechny projekty pro uživatele - je to jednoduchý dotaz pomocí user id / name . Dotaz projekce umožňuje, jaké informace souvisí s project je zobrazen. Můžete použít find nebo aggregate metoda k sestavení dotazu. Můžete se dotazovat na konkrétní project pro user pomocí projectId nebo projectName . Protože na user existují indexy a project pole, bude to efektivní dotaz.
Doporučuji tedy mít jedinou kolekci user_projects , s user informace a projects informace v něm obsažené.