Het voorbeeld dat u geeft is, net als de meeste praktijkvoorbeelden van veel-op-veel-relaties, eigenlijk een voorbeeld van een enkele-op-enkele relatie. Je hebt misschien veel restaurants en veel diners, maar vergeleken met de hele set heeft een bepaald restaurant slechts een kleine subset van diners bediend en de meeste individuele diners hebben slechts een kleine subset van de restaurants bezocht. Het klinkt als een dun gelinkt netwerk waar de linkdichtheidsratio aanzienlijk lager is dan één.
U vroeg echter naar veel-op-veel, dus wat als we een neuraal netwerk als voorbeeld gebruiken? Neurale netwerken vormen vaak dichte netwerken en vertegenwoordigen dus een echt veel-op-veel netwerk. In dat geval is het antwoord eenvoudig - gebruik geen mongoDB. Gebruik aangepaste structuren en serialisatiestrategieën die zijn afgestemd op uw specifieke vereisten. Immers, echte veel-op-veel-relaties zijn bijna altijd uitschieters en rechtvaardigen daarom een specifieke behandeling.
Dat gezegd hebbende, het modelleren van de meer gebruikelijke enkele-tot-enkele relatie in mongoDB kan worden bereikt zonder de rijke documentstructuur op te offeren, en hoe u dit bereikt, hangt af van uw toegangspatronen.
Dus, met het restaurant/dinernetwerk voorbeeld, als u een restaurant normaal gesproken gaat vragen over zijn diners, dan zou u een reeks diner_id's maken die bij elk restaurant worden bewaard. De andere manier zou betekenen dat er een reeks restaurant-id's bij elk diner wordt gehouden. Beide voor tweerichtingsquery's.
Er moet voorzichtigheid worden betracht omdat er geen externe_sleutelbeperking is in mongoDB en daarom is het uw verantwoordelijkheid om de referentiële integriteit van uw gegevens te behouden.
Als prestaties voor u het belangrijkst zijn, wilt u misschien de gegevens in elk document insluiten in plaats van ernaar te verwijzen met een id. Dit is de optie met hogere prestaties voor lezen (niet zozeer voor schrijven), omdat alle gegevens in één keer van de schijf kunnen worden gehaald. Het betekent dat u meer werk moet verzetten wanneer u gegevenswaarden bijwerkt om de integriteit van uw gegevens te waarborgen, maar vaak is dit niet zo eng als het op het eerste gezicht lijkt. Hoe vaak veranderen de diners echt van naam? En afhankelijk van de documentformaten, wil je misschien niet per se het volledige document insluiten, een subset van de gegevens plus een id die naar het volledige record verwijst, zal vaak voldoende zijn.
Kortom, het ontwerp van het mongoDB-schema moet worden aangestuurd door de toepassingsvereisten. Verschillende schema's voor verschillende toepassingen in tegenstelling tot één monolithische relationele database om ze allemaal te beheersen. Wat is de realiteit van de gegevens? Hoe gebruikt de applicatie deze gegevens eigenlijk? Hoe groot zijn de documentobjecten die worden opgeslagen? Beantwoord deze vragen en uw schema zal praktisch zichzelf ontwerpen.