Exemplet du ger, i likhet med de flesta verkliga exempel på många-till-många-relationer, är faktiskt ett exempel på få-till-få relation. Du kan ha många restauranger och många matgäster, men jämfört med hela uppsättningen har varje given restaurang bara serverat en liten delmängd av matgäster och de flesta enskilda matgäster har bara besökt en liten delmängd av restaurangerna. Det låter som ett glest länkat nätverk där länkdensitetsförhållandet är betydligt under ett.
Men du frågade om många-till-många så vad sägs om att vi använder ett neuralt nätverk som exempel? Neurala nätverk bildar ofta täta nätverk och representerar därför ett verkligt många-till-många-nätverk. I så fall är svaret enkelt - använd inte mongoDB. Använd anpassade strukturer och serialiseringsstrategier skräddarsydda för dina specifika krav. När allt kommer omkring är sanna många-till-många-relationer nästan alltid extremvärden och motiverar därför specifik behandling.
Med det sagt, modellera de mer vanliga få-till-få relation i mongoDB kan uppnås utan att offra den rika dokumentstrukturen, och hur du uppnår detta beror på dina åtkomstmönster.
Så, med exemplet på nätverket för restaurang/matställe, om du vanligtvis ska fråga en restaurang på dess matställen, skulle du skapa en uppsättning diner_id för varje restaurang. Det andra sättet skulle innebära en rad restaurang-id's som hålls med varje middag. Båda för tvåvägsfrågor.
Försiktighet måste iakttas eftersom det inte finns någon utländsk nyckel-begränsning i mongoDB och därför är det ditt ansvar att upprätthålla din datas referensintegritet.
Om prestanda är viktigast för dig kanske du vill bädda in data i varje dokument istället för att referera till det med ett id. Detta är det högre prestandaalternativet för läsning (inte så mycket för att skriva) eftersom all data kan dras från disken i en träff. Det betyder att du kommer att behöva göra mer arbete när du uppdaterar datavärden för att säkerställa integriteten hos din data, men ofta är detta inte så skrämmande som det först verkar. Hur ofta byter matgästerna egentligen namn? Och beroende på dokumentstorlekarna kanske du inte nödvändigtvis vill bädda in hela dokumentet, en delmängd av data plus ett id för att peka på hela posten kommer ofta att göra susen.
Kort sagt, mongoDB-schemadesign bör drivas av applikationskraven. Olika scheman för olika applikationer i motsats till en monolitisk relations-DB för att styra dem alla. Hur ser verkligheten ut? Hur använder applikationen egentligen dessa data? Hur stora är dokumentobjekten som lagras? Svara på dessa frågor och ditt schema kommer praktiskt taget att utforma sig självt.