存储与计算重复事件

Question

在简单的日历应用程序中，我特别感兴趣的是了解存储重复事件与计算它们的利弊。我列出了我认为每个人的优点/缺点，但我很好奇是否有人有经验并且可能能够为我提供更明确的推理方式

存储

赞成

• 读取效率（日期范围中的日期是单个索引查询）
• 轻松处理覆盖（只需更新单个项目）

缺点

• 需要一个计算和存储未来事件的过程（前进多远？）
• 进行影响所有事件的更改费用很高（必须更新所有行 - 写得很重）
• 更多数据

计算

赞成

• 无法保持同步
• 高效写入事件（在表格中删除单个条目）
• 少数据

缺点

• 为时间范围生成日历代价昂贵（必须选择所有单个实例事件，然后选择可能重叠的所有重复事件，然后计算重复次数以确定它们是否实际重叠）
• 更难处理排除/覆盖（指定定期事件的覆盖日期，然后为要更改的日期添加单独的单个事件

一般来说，上面的列表似乎指向计算，我认为这对于单个用户/少数用户系统是有意义的。如果要将系统扩展到托管10k +用户及其日历的Exchange服务器，决策是否会改变？

Answer 1

看来你已经总结了利弊。也许他们的组合会更有效。

如果我是你，我通常会计算它，它在运营和批量数据管理方面最具成本效益。然后我存储 excepitonal 。因此，我们可以在我们的用户界面 中说“你想改变这个吗？” 如果我们的答案是否我们仍然只是改变规则。否则我们应该更改规则，但也应该更改例外记录。 这将是我们设计中最具成本效益的东西，但这是一个权衡。

• 遵守规则
• 支持各种特殊的
• 避免大规模交易

但我们还有很多事要做:)这就是人们仍然雇用我们的原因。

Answer 2

这将是使用主要商店存储您的活动以及像redis或memcached这样的辅助商店来存储您的定期活动的理想情况。

首次计算事件的重复发生时，您会将数据推送到辅助商店。从那时起它只是一个查询到redis来获取你的数据。如果要更新事件，只需删除键即可。他们下次你打一个查询时，你会发现它不是redis并重新填充数据。这样您就不必进行任何昂贵的更新。您支付的价格就像任何缓存解决方案，您的第一次计算将是昂贵的。

这将解决存储的第一个第二和第三个问题。

• 需要一个计算和存储未来事件的过程（前进多远？）
• 做出影响所有事件的更改费用昂贵（必须更新所有行 - 写得很重）（Redis速度快，~60K写一秒）
• 更多数据（我称之为元数据？它只是在您的二级缓存存储中）

第一个问题，需要一个计算和存储未来事件的过程这与业务逻辑密切相关。也许它甚至无需计算这些日期即可解决？说实话，我完全不理解用例，所以我甚至不知道是否有必要首先计算和存储重复。

但总的来说，将它存放在您最喜欢的二级商店中。此数据不属于传统的RDBMS或文档数据存储。