Примерът, който давате, както и повечето примери от реалния свят за връзки много към много, всъщност е пример за няколко към малко връзка. Може да имате много ресторанти и много закусвални, но в сравнение с целия набор всеки даден ресторант е обслужвал само малка подгрупа от закусващи и повечето отделни закусващи ще са посетили само малка подгрупа от ресторанти. Звучи като слабо свързана мрежа, където съотношението на плътност на връзката е значително под единица.
Вие обаче попитахте за много към много, така че какво ще кажете да използваме невронна мрежа като пример? Невронните мрежи често образуват плътни мрежи и така представляват истинска мрежа много към много. В този случай отговорът е лесен - не използвайте mongoDB. Използвайте персонализирани структури и стратегии за сериализиране, съобразени с вашите специфични изисквания. В края на краищата истинските връзки много към много почти винаги са извънредни и затова оправдават специфично третиране.
С това казано, моделиране на по-обичайните няколко към малко връзката в mongoDB може да бъде постигната без да се жертва богатата структура на документа и как ще постигнете това зависи от вашите модели за достъп.
И така, с примера с мрежата ресторант/закусвалня, ако обикновено ще правите запитване към ресторант за неговите заведения, тогава ще създадете масив от diner_ids, съхраняван за всеки ресторант. Другият начин би означавал масив от restaurant_ids, съхраняван с всяка вечеря. И двете за възможност за двупосочна заявка.
Трябва да се внимава, тъй като в mongoDB няма ограничение за чужд_ключ и следователно поддържането на референтната цялост на вашите данни е ваша отговорност.
Ако производителността е най-важна за вас, тогава може да искате да вградите данните във всеки документ, вместо да го препращате с идентификатор. Това е опцията с по-висока производителност за четене (не толкова за запис), тъй като всички данни могат да бъдат изтеглени от диска с един удар. Това означава, че ще трябва да свършите повече работа, когато актуализирате стойностите на данните, за да гарантирате целостта на вашите данни, но често това не е толкова страшно, колкото изглежда на пръв поглед. Колко често закусвалните наистина сменят имената си? И в зависимост от размерите на документа, може да не искате непременно да вградите целия документ, подмножество от данни плюс идентификатор, който да сочи към пълния запис, често ще свършат работа.
Накратко, дизайнът на схемата на mongoDB трябва да се ръководи от изискванията на приложението. Различни схеми за различни приложения, за разлика от една монолитна релационна база данни, която да управлява всички тях. Каква е реалността на данните? Как всъщност приложението използва тези данни? Колко големи са обектите на документа, които се съхраняват? Отговорете на тези въпроси и вашата схема на практика ще се проектира сама.
