Důležitým hlediskem při navrhování schématu pro MongoDB není to, co jsou vaše data, ale jak je budete používat. Bez toho, abyste zjistili, jaký typ čtení a zápisu budete provádět (a jak výkonné budou), může být obtížné navrhnout „optimální“ schéma.
Existuje několik základních pokynů, které můžete zvážit, abyste se vyhnuli problémům. Jedním z nich je vyhnout se navrhování dokumentů, které se neomezeně rozrůstají. To znamená, že byste neměli vkládat objednávky do zákaznických dokumentů. Dalším pravidlem je, že věci, které samy o sobě nejsou „zajímavé“ (nebo samy o sobě neexistují), je pravděpodobně lepší, když je vložíte. To naznačuje, že orderItems si nezaslouží vlastní kolekci a mělo by se s nimi jednoduše zacházet jako s atributy objednávek (což ve skutečnosti jsou).
Toto přesné cvičení je pokryto školením vývojářů MongoDB, což je docela typický příklad návrhu schématu.
Sečteno a podtrženo, měli byste mít tři sbírky:
Produkty
Zákazníci
Objednávky
Objednávky budou odkazovat na zákazníky (volitelně denormalizují některé informace ze sbírky zákazníků) a budou odkazovat na produkty (v poli položek orderItems, které budou obsahovat).
Další kolekce a přesná pole ve všech těchto kolekcích závisí na vašem konkrétním případu použití, ale nevidím proveditelný scénář, kdy by bylo možné mít méně kolekcí než tyto tři.