RavenDB Дизайн и производительность вложенных документов

Question

В сценарии вопросов и комментариев ... где комментарии не существуют сами по себе, но хранятся как вложенные элементы в их родительском вопросительном документе ... эти комментарии могут, конечно, наращивать к сотням и сотням записей ... разве я не возьму штраф за исполнение при загрузке вопроса? Не будет ли эта загрузка загружать все сотни и сотни комментариев? Какой запрос мог (должен) я запускать, чтобы загрузить вопрос, но потом загружать только первые 10 комментариев, чтобы иметь возможность загружать еще одну «страницу» комментариев, как мне нужно?

Или RavenDB применяет ленивую загрузку, так как она не загружает комментарии вообще до тех пор, пока я не получу доступ к свойству комментариев экземпляра вопроса? И даже так ... могу ли я контролировать, что он «ленивый» загружает комментарии в постраничном режиме?

Кроме того, как бы добавить новый комментарий к Вопросу без предварительной загрузки вопроса (со всеми его комментариями)?

Answer 1

При загрузке документа вы обычно хотите загрузить все (например, страницу с подробными сведениями в блоге).

Для индексной страницы (включая все записи в блоге) вы можете создать индекс, который делает map/reduce.

Что касается сохранения новых комментариев, вы можете спросить себя, как часто вы это делаете? На большинстве веб-сайтов считывания гораздо чаще используются, чем записи. Таким образом, штраф за производительность для загрузки всего блога не так уместен при просмотре всей картинки.

Но если вы ожидаете получить много комментариев, вы можете захотеть перепроектировать ваше приложение позже, чтобы сделать компиляции корневых агрегатов. Но не делайте этого, пока это не станет проблемой производительности. (Также легко перемещать комментарии благодаря схематическому характеру RavenDB).