Дизайн базы данных документов для форума

Я собираю простой форум, чтобы окунуться в базу данных документов, думая, что это будет относительно прямолинейно моделировать.

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

Таким образом, в основном есть Forums, и на каждом форуме есть группа Threads, и каждая ветка содержит группу Posts, автором которых является Users.

В моей голове я представил себе, что каждый из них должен быть отдельным документом, главным образом потому, что каждый Forum может иметь тысячи Threads, а каждый Thread может иметь тысячи Posts. Кажется, что наличие нечетких документов приведет к тому, что они со временем станут массовыми?

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

Я могу сохранить имя Author в сообщении, так как оно вряд ли изменится, однако количество сообщений Author будет постоянно меняться, поэтому его нельзя сохранить в файле Post.

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

Редактировать

Похоже на Live Projections в RavenDB должны с этим справиться, но я все же хотел бы оставить некоторые комментарии о возможных альтернативных схемах БД.


person ChadT    schedule 08.12.2010    source источник


Ответы (1)


Я думал о действительно похожей ситуации. И я пришел к тому же выводу, что и вы. Но я кое-что забыл, и, возможно, вы тоже забываете: базы данных документов имеют очень денормализованную природу. Таким образом, вы можете использовать живые проекции в ravenDB, но только в особых случаях, потому что обычным делом является дублирование данных. Например:

Почта:

  • ThreadId (необходим для фильтрации)

  • Текст

  • ID автора

  • Имя пользователя

  • АвторПоследнийВход

  • Автор Anything

Таким образом, у вас есть идентификатор автора, если он понадобится вам позже, но у вас будут денормализованные и наиболее часто используемые данные, доступные без объединений или живых проекций.

В случае подсчета количества сообщений автора вы должны использовать индекс карты/уменьшения. Эти индексы постоянно обновляются. Таким образом, когда автор публикует сообщение, его счетчик не будет обновляться сразу, но он будет в конечном счете согласованным. Это важная часть Document DB.

Надеюсь, это поможет

person NicoGranelli    schedule 12.01.2011
comment
Структура, которую вы имеете, в основном то, о чем я думал в любом случае - денормализовав AuthorNames, включенные в сообщение, я только что застрял на AuthorPostCount ... если у кого-то есть 10 000 сообщений ... и они делают еще один, я не хочу иметь обновите 10 000 предыдущих почтовых документов новым значением AuthorPostCount. - person ChadT; 13.01.2011
comment
В дополнение к вышесказанному, при загрузке страницы с 50 сообщениями я также не хочу выполнять 50 дополнительных запросов для загрузки AuthorPostCount для каждого сообщения, даже в его собственном индексе... хммм - person ChadT; 13.01.2011
comment
Понятно... Как насчет того, чтобы привести все 50 сообщений (или меньше, если автор разместил более одного сообщения) в одном запросе? Что-то вроде предложения in в sql. - person NicoGranelli; 04.02.2011
comment
Итак, храним ли мы переменную count в базе данных, которая ведет подсчет количества сообщений этого пользователя? Если да, то не можем ли мы создать еще одну таблицу, в которой есть authorId, threadId и count. count покажет количество постов, опубликованных автором в конкретной теме. Итак, если мы хотим всего нет. сообщений этого автора, мы можем суммировать их. PS: я наивен в базе данных. Ответил исходя из школьных знаний. - person ivorykoder; 19.02.2011