文档设计

Question

我正在尝试一些不同的选项，以便在RavenDB中以有效的方式设计和存储文档结构。

我处理用户的结构是会话和活动跟踪信息。

当用户登录到系统并开始创建活动时，将启动会话。每个会话可能有数百个活动。当用户关闭/注销时，会话结束。

使场景稍微复杂的一个因素是，会话是实时显示在web门户中的。换句话说:我需要跟踪会话和活动，并将它们关联起来，以便能够找出它们是否正在进行(以及它们已经运行了多长时间)或者它们是否已经完成。

当然，您也可以深入挖掘历史。

我做了一些研究，在这里发现了两个关于堆栈溢出的相关问题，但它们都没有真正帮助我：Document structure for RavenDB Activity stream design with RavenDb

我已经成功添加的两个选项是：(简化结构)

1：

{
  "User": "User1",
  "Machine": "machinename",
  "StartTime": "2012-02-13T13:11:52.0000000",
  "EndTime": "2012-02-13T13:13:54.0000000",
  "Activities": [
    {
      "Text": "Loaded Function X",
      "StartTime": "2012-02-13T13:12:10.0000000",
      "EndTime": "2012-02-13T13:12:10.0000000"
    },
    {
      "Text": "Executed action Z",
      "StartTime": "2012-02-13T13:12:10.0000000",
      "EndTime": "2012-02-13T13:12:10.0000000"
    }
}

2：

{
  "Session" : "SomeSessionId-1",
  "User": "User1",
  "Machine": "machinename",
  "Text": "Loaded Function X",
  "StartTime": "2012-02-13T13:12:10.0000000",
  "EndTime": "2012-02-13T13:12:10.0000000"
}

{
  "Session" : "SomeSessionId-1",
  "User": "User1",
  "Machine": "machinename",
  "Text": "Executed action Z",
  "StartTime": "2012-02-13T13:12:10.0000000",
  "EndTime": "2012-02-13T13:12:10.0000000"
}

Alternative 1从关系型背景出发，感觉更自然，加载会话、添加事件和存储都非常简单。每次加载Session对象和附加事件的开销对插入性能来说真的很糟糕。

Alternative 2感觉效率更高，我可以简单地添加事件(几乎就像事件源)。但是，当深入研究事件并在每个会话中显示它们时，选择会变得有点复杂。

有没有第三个更好的选择呢？解决方案可能是分离事件并创建另一个读取模型吗？我是不是把问题复杂化了？

Answer 1

看起来你只需要一个用户文档和一个会话文档。为User和Session创建两个模型。会话文档将把userid作为一个属性。会话也将具有嵌套的"activity“属性。在这种情况下，很容易显示实时的用户-会话-活动。在不了解更多细节的情况下，我当然过于简单化了。

编辑：

//Sample User Document

{
  UserId:"ABC01",
  HomeMachine:"xxxx",
  DateCreated:"12/12/2011"
}


//Sample Session Document

{
  UserId:"ABC01",
  Activities
    {
      Activity 1 properties
    }
    {
      Activity 2 properties
    }
    ...
    ...
    etc..

}

Answer 2

我绝对认为你应该使用选项2的一些变体。在选项1中，文档不会变得非常大吗？这可能会使插入非常慢。我真的不明白为什么在选项2中显示每个会话的事件会比在选项1中更复杂，您可以使用以下命令按会话选择事件

session.Query<Event>().Where(x => x.Session == sessionId)

RavenDB会自动为它创建一个索引。如果您想要进行更复杂的查询，您总是可以为其创建更专门的索引。