Важно съображение при проектирането на схема за MongoDB не е какви са вашите данни, а как ще ги използвате. Без да разберете какъв тип четене и запис ще правите (и колко производителни ще бъдат), може да бъде трудно да се проектира "оптимална" схема.
Има някои основни насоки, които можете да вземете предвид, за да избегнете проблеми. Един от тях е избягване на проектиране на документи, които продължават да растат неограничено. Това означава, че не трябва да вграждате поръчки в клиентски документи. Друго правило е, че неща, които не представляват интерес сами по себе си (или не съществуват сами по себе си), вероятно е по-добре да бъдат вградени. Това предполага, че orderItems не заслужават своя собствена колекция и просто трябва да се третират като атрибути на поръчки (което всъщност са те).
Това точно упражнение е обхванато в обучението за разработчици на MongoDB, което е доста типичен пример за проектиране на схема.
В крайна сметка трябва да имате три колекции:
Продукти
Клиенти
Поръчки
Поръчките ще препращат към клиенти (като по избор денормализират част от информацията от колекцията от клиенти) и ще препращат към продукти (в масива от артикули за поръчка, които ще съдържат).
По-нататъшните колекции и точните полета във всички тези колекции зависят от вашия конкретен случай на употреба, но не виждам осъществим сценарий за по-малко колекции от тези три.
