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>函数，以生成所需的数据。

在“常规”关系表中，这一切都没有问题。无论有没有正常化，这个woulb都是轻而易举的。概念验证基于：它是否会在nosql变体中混合使用？这个问题是因为在被警告这些“重”聚合函数（如嵌套的WHERE约束和SUM等）在文档存储变体中不理想之后我有些疑惑。

考虑到这一切，我有两个问题：

这是否适用于nosql变体，特别是RavenDB？
方法是否正确？

我可以想象，冗余地存储所有数据，而不是在运行中查询，性能会更高。就像添加某个用户在Project（）或Customer（）对象中花费的时间一样。然而，这将大大增加更新的复杂性。更不用说在整个馆藏中创建巨大的冗余数据，这反过来又直接违反了关注和干旱的分离。

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

Answer 1

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

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

如果您只需要（比方说）4个关于该数据的特定视图，那么您可以将这些数据存储在Raven中，应用Map / Reduce索引，并且您将能够以极快的速度访问这些报告，因为它们将会异步更新并始终具有出色的性能，因为数据已经存在，并且在运行时不需要任何事情。当然，然后一些经理会说“你知道如果我们还能看到 _ _ ，那真的很棒。”如果经理的请求需要额外的开发时间来创建新的Map / Reduce索引，UI等，那么Raven仍然可以成为工作的工具。

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

RavenDB中的'重'聚合函数是否可行？

1 个答案: