Относно първия ви въпрос:
Вие специално питате за по-добър начин за работа с детски идентификатори, които се съхраняват в родителя. Почти съм сигурен, че няма по-добър начин да се справим с това, ако трябва да е този модел.
Но този проблем съществува и в релационните бази данни. Ако искате да запазите публикацията си в релационна база данни (използвайки този шаблон), първо трябва да създадете коментара, да получите неговия идентификатор и след това да актуализирате публикацията. Разбира се, можете да изпратите всички тези задачи в една заявка, което вероятно е по-ефективно от използването на mongoose, но видът работа, която трябва да се извърши, е същият.
Относно втория ви въпрос:
Предимството пред вариант А е, че можете например да получите публикацията и незабавно да знаете колко коментара има, без да искате mongodb да прегледа вероятно стотици документи.
Предимството пред вариант B е, че можете да съхранявате повече препратки към коментари в един документ (една публикация), отколкото цяло коментари, поради mongos 16 MB лимит на размера на документа.
Недостатъкът обаче е този, който споменахте, че е неефективно да се поддържа тази структура. Приемам, че това е само пример за показване на сценария, така че ето какво бих направил:бих решил за всеки отделен случай какво да използвам.
-
Ако документът ще се чете много и няма да му се пише много, И малко вероятно е да стане по-голям от 16MB:Вградете поддокумента. по този начин можете да получите всички данни в една заявка.
-
Ако трябва да направите препратка към документа от множество други документиИ вашите данни наистина трябва да са последователни, тогава нямате друг избор, освен да ги препратите.
-
Ако трябва да направите препратка към документа от множество други документиНО съгласуваността на данните не е толкова важна И важат ограниченията от първата точка, след което вградете поддокументите и напишете код, за да поддържате данните си последователни.
-
Ако трябва да направите препратка към документа от множество други документи и те се пишат много, но не се четат толкова често, вероятно е по-добре да ги препращате, тъй като това е по-лесно за кодиране, защото не е необходимо да пишете код за синхронизиране на дублирани данни.
В този конкретен случай (публикация/коментар) позоваване на родителя от детето (уведомяване на детето за родителите _id ) вероятно е добра идея, защото е по-лесно да се поддържа, отколкото обратното, и документът може да стане по-голям от 16 MB, ако са вградени директно. Ако знаех със сигурност, че документът НЯМА да е по-голям от над 16MB, вграждането им би било по-добре, защото по-бързо се правят заявки за данни по този начин
