Можете да избегнете N+1 -проблем със стотици заявки, използващи $in
-запитвания. Помислете за това:
Post {
PosterId: ObjectId
Text: string
Comments: [ObjectId, ObjectId, ...] // option 1
}
Comment {
PostId: ObjectId // option 2 (better)
Created: dateTime,
AuthorName: string,
AuthorId: ObjectId,
Text: string
}
Вече можете да намерите коментарите на публикациите с $in и също така можете лесно да намерите всички коментари, направени от определен автор.
Разбира се, можете също да съхранявате коментарите като вграден масив в публикация и да извършите $in заявка за потребителската информация, когато извличате коментарите. По този начин не е необходимо да денормализирате потребителските имена и пак нямате нужда от стотици заявки.
Ако решите да денормализирате потребителските имена, ще трябва да актуализирате всички коментари, направени някога от този потребител, когато потребител се промени, напр. неговото име. От друга страна, ако такива операции не се случват много често, това не би трябвало да е голяма работа. Или може би е дори по-добре да съхраните името, което потребителят е имал, когато е направил коментара, в зависимост от вашите изисквания.
Общ проблем с вграждането е, че различни писатели ще пишат в един и същи обект
, така че ще трябва да използвате атомарните модификатори
(като $push ). Това понякога е по-трудно за използване с картографи (все пак не познавам mongoalchemy) и като цяло е по-малко гъвкаво.
