3

我正在使用 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 的分离。

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

4

1 回答 1

2

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

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

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

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

于 2013-10-09T19:25:09.810 回答