Een belangrijke overweging bij het ontwerpen van een schema voor MongoDB is niet wat uw gegevens zijn, maar hoe u deze gaat gebruiken. Zonder uit te zoeken wat voor soort lees- en schrijfbewerkingen u gaat doen (en hoe goed ze zullen zijn), kan het moeilijk zijn om een "optimaal" schema te ontwerpen.
Er zijn enkele basisrichtlijnen die u kunt overwegen om te voorkomen dat u in de problemen komt. Een daarvan is het vermijden van het ontwerpen van documenten die grenzeloos blijven groeien. Dat betekent dat u geen bestellingen in klantdocumenten moet insluiten. Een andere regel is dat dingen die op zichzelf niet "interessant" zijn (of niet op zichzelf bestaan), waarschijnlijk beter kunnen worden ingebed. Dit suggereert dat orderItems geen eigen verzameling verdienen en gewoon moeten worden behandeld als attributen van bestellingen (wat ze in feite zijn).
Deze exacte oefening wordt behandeld in de MongoDB-ontwikkelaarstraining, een vrij typisch voorbeeld van schemaontwerp.
Het komt erop neer dat je drie collecties zou moeten hebben:
Producten
Klanten
Bestellingen
Bestellingen verwijzen naar klanten (optioneel denormaliseren sommige informatie uit de verzameling van klanten) en ze verwijzen naar producten (in de reeks orderItems die ze zullen bevatten).
Verdere verzamelingen en exacte velden in al deze verzamelingen zijn afhankelijk van uw specifieke gebruiksscenario, maar ik zie geen haalbaar scenario om minder verzamelingen dan deze drie te hebben.