Das Beispiel, das Sie geben, ist wie die meisten realen Beispiele für viele-zu-viele-Beziehungen tatsächlich ein Beispiel für wenige-zu-wenige Beziehung. Sie haben vielleicht viele Restaurants und viele Gäste, aber im Vergleich zum gesamten Set hat jedes Restaurant nur eine kleine Teilmenge von Gästen bedient, und die meisten einzelnen Gäste haben nur eine kleine Teilmenge der Restaurants besucht. Es klingt nach einem spärlich verknüpften Netzwerk, bei dem das Linkdichteverhältnis deutlich unter eins liegt.
Sie haben jedoch nach Many-to-Many gefragt. Wie wäre es also, wenn wir ein neuronales Netzwerk als Beispiel verwenden? Neuronale Netze bilden oft dichte Netze und stellen somit ein echtes Many-to-Many-Netzwerk dar. In diesem Fall ist die Antwort einfach:Verwenden Sie MongoDB nicht. Verwenden Sie individuelle Strukturen und Serialisierungsstrategien, die auf Ihre spezifischen Anforderungen zugeschnitten sind. Schließlich sind echte Viele-zu-Viele-Beziehungen fast immer Ausreißer und rechtfertigen daher eine besondere Behandlung.
Nachdem dies gesagt wurde, modellieren wir das üblichere wenige zu wenigen Beziehung in mongoDB kann erreicht werden, ohne die reichhaltige Dokumentstruktur zu opfern, und wie Sie dies erreichen, hängt von Ihren Zugriffsmustern ab.
Wenn Sie also im Beispiel des Restaurant-/Diner-Netzwerks normalerweise ein Restaurant nach seinen Gästen abfragen, würden Sie ein Array von Diner_ids erstellen, die bei jedem Restaurant gespeichert sind. Der andere Weg würde ein Array von restaurant_ids bedeuten, die bei jedem Diner vorhanden sind. Beide für bidirektionale Abfragefähigkeit.
Es ist Vorsicht geboten, da es in mongoDB keine Foreign_Key-Einschränkung gibt und daher die Aufrechterhaltung der referenziellen Integrität Ihrer Daten in Ihrer Verantwortung liegt.
Wenn Ihnen die Leistung am wichtigsten ist, möchten Sie die Daten möglicherweise in jedes Dokument einbetten, anstatt sie mit einer ID zu referenzieren. Dies ist die leistungsstärkere Option zum Lesen (nicht so sehr zum Schreiben), da alle Daten mit einem Schlag von der Festplatte gezogen werden können. Dies bedeutet, dass Sie mehr Arbeit leisten müssen, wenn Sie Datenwerte aktualisieren, um die Integrität Ihrer Daten sicherzustellen, aber oft ist dies nicht so beängstigend, wie es zunächst scheint. Wie oft ändern die Gäste wirklich ihre Namen? Und abhängig von der Dokumentgröße möchten Sie möglicherweise nicht unbedingt das vollständige Dokument einbetten, eine Teilmenge der Daten plus eine ID, die auf den vollständigen Datensatz verweist, reicht oft aus.
Kurz gesagt, das MongoDB-Schemadesign sollte von den Anwendungsanforderungen bestimmt werden. Unterschiedliche Schemata für unterschiedliche Anwendungen im Gegensatz zu einer monolithischen relationalen Datenbank, die alle beherrscht. Was ist die Realität der Daten? Wie verwendet die Anwendung diese Daten eigentlich? Wie groß sind die zu speichernden Dokumentobjekte? Beantworten Sie diese Fragen und Ihr Schema wird sich praktisch von selbst entwerfen.
