Příklad, který uvádíte, je společný s většinou skutečných příkladů vztahů mnoho k mnoha, je ve skutečnosti příkladem několika k několika vztah. Můžete mít mnoho restaurací a mnoho strávníků, ale ve srovnání s celým souborem jakákoli daná restaurace servírovala pouze malou podskupinu strávníků a většina jednotlivých strávníků navštívila pouze malou podskupinu restaurací. Zní to jako řídce propojená síť, kde je poměr hustoty připojení výrazně nižší než jedna.
Ptali jste se však na many-to-many, tak co kdybychom jako příklad použili neuronovou síť? Neuronové sítě často tvoří husté sítě, a tak představují skutečnou síť typu many-to-many. V takovém případě je odpověď snadná – nepoužívejte mongoDB. Používejte vlastní struktury a strategie serializace přizpůsobené vašim konkrétním požadavkům. Koneckonců, skutečné vztahy mnoho k mnoha jsou téměř vždy odlehlé, a tak ospravedlňují specifické zacházení.
To znamená, že modelování obvyklejších několika k několika vztahu v mongoDB lze dosáhnout bez obětování bohaté struktury dokumentů a jak toho dosáhnete, závisí na vašich přístupových vzorech.
Takže v příkladu sítě restaurace / restaurace, pokud se obvykle chystáte dotazovat restauraci na její hosty, pak byste vytvořili pole diner_ids uchovávaných u každé restaurace. Jiný způsob by znamenal řadu identifikátorů restaurant_id uložených u každého strávníka. Oba pro možnost obousměrného dotazování.
Je třeba dávat pozor, protože v mongoDB neexistuje žádné omezení cizího_klíče, a proto je vaší odpovědností udržovat referenční integritu vašich dat.
Je-li pro vás nejdůležitější výkon, možná budete chtít vložit data do každého dokumentu a ne na ně odkazovat pomocí ID. Toto je výkonnější možnost pro čtení (ne tolik pro zápis), protože všechna data lze stáhnout z disku jedním zásahem. Znamená to, že při aktualizaci hodnot dat budete muset udělat více práce, abyste zajistili integritu svých dat, ale často to není tak děsivé, jak se na první pohled zdá. Jak často si strávníci opravdu mění jména? A v závislosti na velikosti dokumentu nemusíte nutně chtít vložit celý dokument. Často postačí podmnožina dat plus ID, které ukazuje na celý záznam.
Stručně řečeno, návrh schématu mongoDB by se měl řídit požadavky aplikace. Různá schémata pro různé aplikace na rozdíl od jedné monolitické relační databáze, která je ovládá všechny. Jaká je realita dat? Jak aplikace tato data vlastně využívá? Jak velké jsou uložené objekty dokumentů? Odpovězte na tyto otázky a vaše schéma se prakticky navrhne samo.