MongoDB的文檔設計徵求意見（和他們的答覆意見）

Question

我有一個模型，看起來像：

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可能是「產品」，而條款ArticleID將是產品ID ...

我將使用MongoDB中存儲這些數據

我希望能夠回覆評論，並分層存儲響應 我應該在評論文檔中存儲列表嗎？

我read this文章羅布阿什頓這是合理的事情，比如博客文章，它的評論...

然而，在我的模型，「回覆意見」直接引用父評論。

評論回覆也可能有答覆，使他們x水平深... ...？ 這是否超出了map縮減類型查詢的範圍？

編輯：

「物品」可能是壞的術語 - ArticleType和條款ArticleID只是一個綁評論到特定的「東西」的方式 - 例如，如果我們評論這個問題，articleType可能是stackOverflowQuestion和id是5144273

如果我們在eBay拍賣評論，我們可以有articleType eBay和條款ArticleID爲1234902493984（項目編號）

希望更有意義......

Answer 1

我看到三個更多鈔票的解決方案（這只是我的意見）：

1.

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

優點：你可以很容易的負載，顯示分層數據。你不知道家長對評論的評論。
缺點：您無法使用某個ID查詢和更新評論。

2.

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

優點：只要你想你可以查詢/更新。
缺點：當您需要加載層次結構時，需要mongo的大量請求。

3.My最喜歡的）：

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

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

優點：可以查詢/更新，只要你想。您可以在一個請求中加載包含所有評論的文章。無需存儲還原物ArticleType和ArticleId
缺點：需要加載文章並在內存中構建層次結構。

希望這有助於你做出的選擇..

Answer 2

評論回覆也可能甚至有答覆，使他們深X ...的水平？

所以，如果你想模擬這個，簡單的方法是給每個評論一個評論屬性列表。這給你一個適合數據的自然分層結構。

這是否超出了map縮減類型查詢的範圍？

不。Map函數只是一個JavaScript方法。它可以調用其他方法，它可以遞歸地走樹。

你的模型：令我擔心你提出的模型

一件事是，你有一個ID和一個條款ArticleID和ArticleType？你打算如何訪問這個對象？你正在計劃什麼類型的索引？

是否會在文章範圍之外訪問評論信息？ 你打算用「文章」加載評論嗎？ 在文章本身中只存儲List<Comments>是否有意義？

有幾種方法可以對這些數據建模。所以這實際上取決於你想要得到什麼。您無法針對每個可能的查詢進行優化。如果您可以告訴我們您想快速查詢哪些查詢和用例，則可以更輕鬆地爲建模數據提供建議。