RavenDB 为日历应用程序建模答案

【问题标题】：RavenDB Modeling a Calendar applicationRavenDB 为日历应用程序建模
【发布时间】：2012-10-13 07:08:24
【问题描述】：

我是第一次尝试 Ravendb，并尝试建立一个锻炼应用程序的模型。这是一个我不知道如何安排的类的简单示例。

User{
string:Name
string:Email
//+ 20 or so more properties

}

CalendarEntry{
DateTime:TimeStamp
decimal:Weight
decimal:Waist
List<Meal> Meals
List<WorkoutSession> WorkoutSessions
//+ more properties

}

成员将更新他们的训练日历，包括体重、腰围、每日锻炼次数、食物摄入量和卡路里等。所以日历条目的列表每天都会增加。

所以问题是，用户对象应该包含日历条目列表，还是应该将其用作自己的实体集合，并带有指向用户的引用 ID？

我主要关心的是 Ravendb 中的最大文档大小（有吗？）因为列表每天都在增长，而且如果日历条目是嵌套集合，一年左右后用户文档可能会变得太重.

任何建议将不胜感激

//金

【问题讨论】：

标签： c# nosql data-modeling ravendb modeling

【解决方案1】：

我不知道 Raven 中的任何文档大小限制，但您的第二种方法仍然听起来更好......日历条目对象本身看起来相当大，因此它最终可能会进一步损害性能如果每个用户的日历条目集合变得很大。

但您真正需要问的问题是如何使用数据？您是否可能想要查询数据库中的所有日历条目，而不考虑用户？或者在给定的时间段内？如果答案是肯定的，那么您最好将日历条目存储在它们自己的集合中，以便为它们优化索引。

在 raven 中管理文档之间的“外键”相当容易，所以这应该不会太难完成。本页详细介绍了您如何处理文档关系：http://ravendb.net/docs/client-api/querying/handling-document-relationships

【讨论】：

我也在考虑这个问题，我将如何查询数据。大多数情况下，它真的很简单。例如 GetAllEntriesByUserId(userI)。但是可能在某个地方我想比较不同的人的 excersize 长度，excersize 类型......所以我会选择后者，使用日历条目作为它自己的集合，每个条目中都有一个 UserRefId。但是您在将 CalendarEntry 设置为自己的实体集合时没有发现基本的建模错误？
正确，所描述的模型完全可以接受且可持续。