L'exemple que vous donnez, en commun avec la plupart des exemples réels de relations plusieurs à plusieurs, est en fait un exemple de peu à peu relation. Vous pouvez avoir de nombreux restaurants et de nombreux convives mais, par rapport à l'ensemble, un restaurant donné n'a servi qu'un petit sous-ensemble de convives et la plupart des convives individuels n'auront visité qu'un petit sous-ensemble de restaurants. Cela ressemble à un réseau peu relié où le rapport de densité de liens est nettement inférieur à un.
Cependant, vous avez posé une question sur plusieurs à plusieurs, alors que diriez-vous d'utiliser un réseau de neurones comme exemple ? Les réseaux de neurones forment souvent des réseaux denses et représentent ainsi un véritable réseau plusieurs-à-plusieurs. Dans ce cas, la réponse est simple - n'utilisez pas mongoDB. Utilisez des structures personnalisées et des stratégies de sérialisation adaptées à vos besoins spécifiques. Après tout, les véritables relations plusieurs-à-plusieurs sont presque toujours des valeurs aberrantes et justifient donc un traitement spécifique.
Cela dit, modéliser le plus habituel peu à peu relation dans mongoDB peut être obtenue sans sacrifier la structure riche du document, et la façon dont vous y parvenez dépend de vos modèles d'accès.
Ainsi, avec l'exemple du réseau restaurant / restaurant, si vous allez généralement interroger un restaurant sur ses convives, vous créerez un tableau de diner_ids détenus avec chaque restaurant. L'autre manière signifierait un tableau de restaurant_ids détenu avec chaque restaurant. Les deux pour la capacité de requête bidirectionnelle.
Des précautions doivent être prises car il n'y a pas de contrainte de clé étrangère dans mongoDB et donc le maintien de l'intégrité référentielle de vos données est de votre responsabilité.
Si les performances sont les plus importantes pour vous, vous pouvez intégrer les données dans chaque document plutôt que de les référencer avec un identifiant. Il s'agit de l'option la plus performante pour la lecture (pas tellement pour l'écriture) car toutes les données peuvent être extraites du disque en un seul coup. Cela signifie que vous devrez faire plus de travail lorsque vous mettez à jour les valeurs des données pour garantir l'intégrité de vos données, mais souvent ce n'est pas aussi effrayant qu'il n'y paraît à première vue. À quelle fréquence les convives changent-ils vraiment de nom ? Et selon les tailles de document, vous ne voudrez peut-être pas nécessairement intégrer le document complet, un sous-ensemble de données plus un identifiant pour pointer vers l'enregistrement complet feront souvent l'affaire.
En bref, la conception du schéma mongoDB doit être guidée par les exigences de l'application. Différents schémas pour différentes applications par opposition à une base de données relationnelle monolithique pour les gouverner toutes. Quelle est la réalité des données ? Comment l'application utilise-t-elle réellement ces données ? Quelle est la taille des objets de document stockés ? Répondez à ces questions et votre schéma se construira pratiquement de lui-même.
