Ważną kwestią podczas projektowania schematu dla MongoDB nie jest to, jakie są Twoje dane, ale jak będziesz ich używać. Bez ustalenia, jakiego rodzaju odczyty i zapisy będziesz wykonywać (i jak będą one wydajne), zaprojektowanie „optymalnego” schematu może być trudne.
Istnieje kilka podstawowych wskazówek, które możesz wziąć pod uwagę, aby uniknąć problemów. Jednym z nich jest unikanie projektowania dokumentów, które rosną bez ograniczeń. Oznacza to, że nie należy osadzać zamówień w dokumentach klienta. Inną zasadą jest to, że rzeczy, które same w sobie nie są „interesujące” (lub same w sobie nie istnieją), prawdopodobnie lepiej osadzić. Sugeruje to, że orderItems nie zasługują na swoją własną kolekcję i powinny być po prostu traktowane jako atrybuty zamówień (co w rzeczywistości jest tym, czym są).
To dokładne ćwiczenie jest omówione w szkoleniu dla programistów MongoDB, będącym dość typowym przykładem projektowania schematu.
Podsumowując, powinieneś mieć trzy kolekcje:
Produkty
Klienci
Zamówienia
Zamówienia będą odnosić się do klientów (opcjonalnie denormalizując niektóre informacje z kolekcji klientów) i będą odnosić się do produktów (w tablicy zamówień, które będą zawierać).
Dalsze kolekcje i dokładne pola we wszystkich tych kolekcjach zależą od konkretnego przypadku użycia, ale nie widzę realnego scenariusza, aby mieć mniej kolekcji niż te trzy.
