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关系模型

回答

相关问题