Eine wichtige Überlegung beim Entwerfen eines Schemas für MongoDB ist nicht, was Ihre Daten sind, sondern wie Sie sie verwenden werden. Ohne herauszufinden, welche Art von Lese- und Schreibvorgängen Sie durchführen werden (und wie leistungsfähig sie sein werden), kann es schwierig sein, ein "optimales" Schema zu entwerfen.
Es gibt einige grundlegende Richtlinien, die Sie berücksichtigen können, um Probleme zu vermeiden. Eine davon ist, Dokumente zu vermeiden, die ins Unendliche wachsen. Das bedeutet, dass Sie Bestellungen nicht in Kundendokumente einbetten sollten. Eine andere Regel ist, dass Dinge, die für sich genommen nicht "interessant" sind (oder nicht für sich alleine existieren), wahrscheinlich besser eingebettet sind. Dies deutet darauf hin, dass orderItems keine eigene Sammlung verdienen und einfach als Attribute von Bestellungen behandelt werden sollten (was sie tatsächlich sind).
Genau diese Übung wird in der MongoDB-Entwicklerschulung behandelt, die ein ziemlich typisches Beispiel für Schemadesign ist.
Unterm Strich sollten Sie drei Sammlungen haben:
Produkte
Kunden
Bestellungen
Bestellungen beziehen sich auf Kunden (optional durch Denormalisierung einiger Informationen aus der Kundensammlung) und auf Produkte (in dem Array von Bestellartikeln, die sie enthalten).
Weitere Sammlungen und genaue Felder in all diesen Sammlungen hängen von Ihrem spezifischen Anwendungsfall ab, aber ich sehe kein realisierbares Szenario, weniger Sammlungen als diese drei zu haben.
