RavenDB關係模型

我正在開發一個側面項目來創建一個建立在RavenDB之上的論壇。我目前正在嘗試計算主題作者和主題上的「最後回覆」用戶之間的關係。在一個典型的關係模型中，我只需將FK存儲到發佈該主題的用戶，並與回覆表進行聯結以獲取最近的回覆作者。這顯然不是Raven或任何文檔商店的用例。RavenDB關係模型

什麼是最「最佳」的方式來拉斷？目前我正在圍繞一些想法進行折騰。

理念1：保存在主題模型的作者的FK，添加JsonIgnored用戶對象，我會通過對主題負載填充一個在我的會話負載（這樣一個請求，從客戶端包含到目前爲止，只是使負載本身和模型有點複雜）。然後可能使用map-reduce索引來獲取最近的回覆作者（或甚至與獲取主題作者相同的方法，因此有1或2個查詢依賴）。

想法2：保存模型上的作者和最近的答覆用戶。這裏主要的「問題」是陳舊數據的可能性（例如，如果用戶名改變）。但是，使用後臺任務可能會緩解這種情況（或者在更新用戶文檔並回溯用戶的所有帖子時牢記這一點）。

有問題的模型的示例。

public class User 
{ 
    public string Id { get; set; } 
    public string UserName { get; set; } 
    public string PasswordHash { get; set; } 
} 

public class Topic 
{ 
    public string Id { get; set; } 
    public string Title { get; set; } 
    public string Body { get; set; } 

    // Idea 1 Relationships 
    public string AuthorId { get; set; } 
    [JsonIgnore] 
    public User Author { get; set; } // Would need to be populated on loads from an Include on AuthorId 
    public string MostRecentReplyUserId { get; set; } 
    [JsonIgnore] 
    public User MostRecentReplyUser { get; set; } // Same as Author 

    // Idea 2 Relationships 
    public User Author { get; set; } 
    public User MostRecentReplyUser { get; set; } 
}

注：我可能會一個方法添加到用戶模型返回一個「乾淨」的版本，我擦了東西，像PasswordHash和使用上的保存爲理念2.

來源

2016-02-29 Justin Packwood

根據在更新和查詢性能兩種情況下，您的需求可能是更好的選擇。

我個人會建議第一個想法，因爲當用戶記錄中的某些數據發生更改時，您不需要更新現有文檔。使用包含查詢/加載時間是ravendb的一個很好的功能，它可以幫助您從數據庫中檢索嵌套記錄。只要確保您不忘記包含所有嵌套文檔 - 否則您可能會獲得多次往返。

如果您的數據處理與數據檢索分離，並且在轉換數據時無法訪問數據庫會話，則嵌入文檔（如想法1但帶有用戶的存儲值）可能會更好一些到前端。我們正在使用這樣一個系統，嚴重依賴於這個系統（獲取一個輸入並映射出值的json掛件） - 這將數據檢索邏輯完全從輸出（如映射到json）邏輯中分離出來。缺點：您必須確保每當用戶發生變化時，現有（嵌入式）數據都會得到更新，並且通過網絡傳輸的數據超出想法1的數據。

來源

2016-03-01 18:21:16

RavenDB關係模型

回答

相關問題