Разработка документа MongoDB для комментариев (и их ответных комментариев) - PullRequest
Новая
       16

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

2 голосов
/ 28 февраля 2011

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

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; } 
}

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

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

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

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

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

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

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

"article", вероятно, неверная терминология - ArticleType и ArticleId были просто способом связываниякомментарий к определенной «вещи» - например, если бы мы комментировали этот вопрос, то articleType мог бы иметь значение stackOverflowQuestion, а id был бы 5144273

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

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

Ответы [ 2 ]

1 голос
/ 28 февраля 2011

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

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

Это не входит в объем запроса типа сокращения карты?

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

Ваша модель:

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

Будет ли доступ к информации комментариев за рамками статьи?Собираетесь ли вы загружать комментарии с помощью «статьи»?Имеет ли смысл просто хранить List<Comments> внутри самой статьи?

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

1 голос
/ 28 февраля 2011

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

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
Минусы: Нужно загрузить статью и построить иерархию в памяти.

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

...