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

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

2 голосов
/ 08 декабря 2010

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

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

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

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

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

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

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

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

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

1 Ответ

1 голос
/ 13 января 2011

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

Сообщение:

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

  • Текст

  • AuthorId

  • AuthorUsername

  • AuthorLastLogin

  • AuthorAnything

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

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

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

...