Дизайн документа MongoDB для комментариев (и их ответных комментариев)

У меня есть модель, которая выглядит так:

class Comment {
    public string ID { get; set; }
    public string ArticleType { get; set; }
    public string ArticleID { get; set; }
    public string Body { get; set; }

    public DateTime DateCreated { get; set; }

    public string UserID { get; set; } 
}

Я создаю приложение для хранения комментариев о других вещах в нашем приложении. Например, если комментарий касается продукта, тип статьи может быть «продуктом», а идентификатор статьи — идентификатором продукта...

Я собираюсь использовать mongodb для хранения этих данных.

Я хочу иметь возможность отвечать на комментарий и хранить ответ в иерархическом порядке. Должен ли я хранить список в документе с комментариями?

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

Однако в моей модели «ответные комментарии» относятся непосредственно к родительскому комментарию.

Ответы на комментарии также могут содержать ответы, делая их x уровнями глубины...? Будет ли это выходить за рамки запроса типа уменьшения карты?

Изменить:

«статья», вероятно, является плохой терминологией — ArticleType и ArticleId были просто способом привязать комментарий к конкретной «вещи» — например, если мы комментируем этот вопрос, articleType может быть stackOverflowQuestion, а идентификатор — 5144273.

Если бы мы комментировали аукцион ebay, у нас мог бы быть articleType как ebay и articleId как 1234902493984 (номер товара).

Надеюсь, это имеет больше смысла...


nosql c# mongodb schema document-database
person Alex    schedule 28.02.2011    source источник
comment
Итак, какова цель ID? Является ли ArticleType + ArticleID уникальным? Если это так, то вы, вероятно, можете переопределить существующий идентификатор и сэкономить место в индексе.   -  person Gates VP    schedule 01.03.2011
comment
Другой вопрос, на который вы не ответили: какие запросы вы планируете оптимизировать?   -  person Gates VP    schedule 01.03.2011

Ответы (2)


arrow_upward
1
arrow_downward

Я вижу три возможных решения (это только мое мнение):

1.

public class Comment 
{
  ...
  public List<Comment> ChildComments {get;set;}
}

Плюсы: вы можете легко загружать и отображать иерархические данные. вы не отличаете родительский комментарий от комментария.
Минусы: вы не можете запросить и обновить комментарий с каким-либо идентификатором.

2.

public class Comment 
{
  ...
  public string ParentCommentId {get;set;}
}

Плюсы. Вы можете запрашивать/обновлять по своему усмотрению.
Минусы: Большое количество запросов к монго, когда вам нужна иерархия загрузки.

3.Мой любимый ;) :

 public class Comment 
 {
   ...
   public string ParentCommentId {get;set;}
 }

 public class Article
 {
   ...
   public List<Comment> Comments {get;set;}
 }

Плюсы. Вы можете запрашивать/обновлять по своему усмотрению. Вы можете загрузить статью со всеми комментариями одним запросом. Нет необходимости хранить избыточные ArticleType и ArticleId.
Минусы: необходимо загружать статьи и создавать иерархию в памяти.

Надеюсь, это поможет вам сделать выбор ..

person Andrew Orsich    schedule 28.02.2011

arrow_upward
1
arrow_downward

Ответы на комментарии также могут иметь ответы, что делает их глубокими на x уровней...?

Итак, если вы хотите смоделировать это, простой способ сделать это — дать каждому комментарию список свойств Comments. Это дает вам естественную иерархическую структуру, которая соответствует данным.

Будет ли это выходить за рамки запроса типа уменьшения карты?

Нет. Функция Map — это просто метод javascript. Он может вызывать другие методы, может рекурсивно обходить дерево.

Ваша модель:

Одна вещь, которая меня беспокоит в предложенной вами модели, заключается в том, что у вас есть идентификатор, идентификатор статьи и тип статьи? Как именно вы планируете получить доступ к этому объекту? Какие типы индексов вы планировали?

Будет ли информация о комментариях доступна за рамками статьи? Вы собираетесь грузить комментарии "статьей"? Имеет ли смысл просто хранить List<Comments> внутри самой статьи?

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

person Gates VP    schedule 28.02.2011