c# - RavenDB 中的 'heavy' 聚合函数是否可取？

Question

我正在使用 C# 开发一个概念验证时间表应用程序，它允许用户简单地输入大量时间表记录。概念验证将使用 RavenDB 作为存储提供程序，但是下面的问题可能与一般的 nosql 概念更相关。

用户通常会在每个工作日输入 1 到大约 10 条记录。我们只是说，为了便于讨论，到年底会有很多记录(数万或数十万)用于此特定集合。

记录的模型将定义为:

class TimesheetRecord {
    public long Id { get; set; }
    public int UserId { get; set; }
    public bool IsApproved { get; set; }
    public DateTime DateFrom { get; set; }
    public DateTime DateTill { get; set; }
    public int? ProjectId { get; set; }
    public int? CustomerId { get; set; }
    public string Description { get; set; }
}

从逻辑上讲，该应用程序将允许用户或项目经理即时创建报告。想想像这样的即时报告:

• 为项目、客户或用户花费的总时间
• 在特定时间段(例如一周、一个月或特定日期之间)为项目或客户花费的时间
• 用户或所有用户尚未批准的总小时数
• 等等

当然，可以选择添加其他字段，例如周数、月份等的整数，以减少按日期/时间段过滤所需的运算量。这个想法是基本上使用 Query<T>按偏好运行以生成所需的数据。

在“常规”关系表中，这一切都没有问题。不管有没有规范化，这都是一件轻而易举的事。概念验证基于:它会在 nosql 变体中混合吗？这个问题是因为在被警告这些“重”聚合函数(如嵌套 WHERE 约束和 SUM 等)在文档存储变体中不是理想的之后，我有一些疑问。

考虑到所有这些，我有两个问题:

1. 这在 nosql 变体中是否可取，特别是 RavenDB？
2. 方法是否正确？

我可以想象以冗余方式存储所有数据，而不是即时查询，性能会更高。就像添加某个用户在 Project() 或 Customer() 对象中花费的时间一样。然而，这将大大增加更新的复杂性。更不用说在整个集合中创建大量冗余数据，这反过来似乎直接违反了关注点分离和 DRY。

任何建议或想法都会很棒!

Answer 1

我是 RavenDB 的忠实粉丝，但它不是银弹或金锤。在某些情况下，它不是完成这项工作的最佳工具，而这可能就是其中之一。

具体来说，一般的文档数据库，尤其是 RavenDB，在特定数据访问模式未知时不太适用。 RavenDB 能够创建 Map/Reduce 索引，这些索引可以通过聚合数据做一些惊人的事情，但您必须提前知道您希望如何聚合它。

如果您只需要(假设)该数据的 4 个特定 View ，那么您可以将该数据存储在 Raven 中，应用 Map/Reduce 索引，并且您将能够以惊人的速度访问这些报告，因为它们将异步更新并始终以出色的性能可用，因为数据已经存在并且在运行时无需处理任何内容。当然，有些经理会说“你知道，如果我们也能看到__，那就太好了。”如果经理的请求需要额外的开发时间来创建新的 Map/Reduce 索引、UI 等并没有关系，那么 Raven 仍然可以成为完成这项工作的工具。

但是，这听起来像是您有一个包含基本上完全适合 Excel 的数据表的场景，并且您希望能够以在运行时之前无法知道的疯狂方式查询该数据。在这种情况下，您最好使用关系数据库。它们专为该任务而创建，并且非常擅长。