是否建议在 RavenDB 中使用“繁重”聚合函数

本文关键字：繁重 函数 RavenDB 是否 | 更新日期: 2023-09-27 18:34:32

我正在开发一个 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 的分离。

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

是否建议在 RavenDB 中使用“繁重”聚合函数

我是RavenDB的忠实粉丝，但它不是银弹或金锤。它有一些场景，它不是工作的最佳工具，这可能是其中之一。

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

如果您只需要(假设(该数据的 4 个特定视图，那么您可以将该数据存储在 Raven 中，应用 Map/Reduce 索引，您将能够以极快的速度访问这些报告，因为它们将异步更新并始终以出色的性能提供，因为数据已经存在，运行时无需处理任何内容。当然，然后一些经理会说："你知道如果我们也能看到__，那将是真正的好事。如果经理的请求需要额外的开发时间来创建新的 Map/Reduce 索引、UI 等，那么 Raven 仍然可以成为这项工作的工具。

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

相关文章：