对时间表中无限重复的任务进行建模（类似日历的 Rails 应用程序）

Question

这一直是一个很大的绊脚石。警告：以下不是问题，而是对我的想法的解释。我的问题是——你有更好的方法吗？是否有一些我不熟悉的常用技术？看来这是一个微不足道的问题。

所以你有任务模型。您可以创建任务、完成任务、销毁任务。然后你就有重复的任务。它就像常规任务一样，但附加了重复规则。但是，任务可以无限期地重复 - 您可以将计划提前一年，并且您应该看到任务显示。

因此，当用户创建重复任务时，您不想在未来数百年内构建数千个任务，并将它们保存到数据库中，对吧？所以我开始思考——如何创建它们？

一种方法是在您查看日程安排时创建它们。因此，当用户提前一个月移动时，将创建任何重复任务。当然，这意味着您不能再简单地处理任务的数据库记录。您对任务执行的每个 SELECT 操作都必须在特定日期范围的上下文中，以便触发该日期范围内的重复任务持续存在。这是维护和性能的负担，但也是可行的。

好吧，但是原来的任务呢？每个重复任务都与创建它的重复规则相关联，并且每个重复规则都需要知道启动重复的原始任务。后者很重要，因为您需要在用户浏览其日程安排时将原始任务克隆到新日期。我想也是可行的。

但是如果原始任务更新了会发生什么？这意味着现在当我们浏览计划时，我们将创建从修改后的任务克隆的重复任务。这是不可取的。所有隐式保留的重复任务都应显示为添加重复任务时原始任务的样子。因此，我们需要单独存储原始任务的副本，并从中克隆，以便重复工作。

但是，当用户导航计划中的任务时，我们如何知道在特定点是否需要创建新的重复任务？我们问重复规则：“嘿，我应该坚持这一天的任务吗？”它说是或否。如果这一天已经有一个重复任务，我们就不会创建任务。一切都很好，除了用户还应该能够简单地删除已自动保留的重复任务之一。在这种情况下，按照我们的逻辑，系统将重新创建已删除的任务。不好。因此，这意味着我们需要继续存储该任务，但将其标记为本次重复的已删除任务。嗯。

正如我在一开始所说的，我想知道是否有人解决了这个问题并且可以在这里提供架构建议。有必要这么乱吗？我还缺少什么更优雅的东西吗？

更新：由于这个问题很难完美回答，所以我会批准对设计/架构最有帮助的见解，它对此类问题具有最佳的帮助/权衡比。它不必包含所有细节。

Answer 1

我知道这是一个老问题，但我刚刚开始为自己的应用程序研究这个问题，我发现 Martin Fowler 的这篇论文很有启发性： 日历的重复事件

对我来说，主要的收获是使用他所谓的“时间表达式”来确定预订是否在某个日期范围内，而不是尝试插入无限数量的事件（或者在您的情况下）任务）存入数据库。

实际上，对于您的用例，这可能意味着您使用名为 schedule 的“时间表达式”属性来存储任务。 ice_cube 循环 gem 能够将自身序列化为活动记录属性像这样：

class Task < ActiveRecord::Base
  include IceCube
  serialize :schedule, Hash

  def schedule=(new_schedule)
    write_attribute(:schedule, new_schedule.to_hash)
  end

  def schedule
    Schedule.from_hash(read_attribute(:schedule))
  end
end

Icecube 看起来非常灵活，甚至允许您指定重复规则的例外情况。 （假设您只想删除该任务的一次出现，而不是全部。）

问题是您无法真正在数据库中查询属于特定日期范围内的任务，因为您只存储了制定任务的规则，而不是任务本身。对于我的情况，我正在考虑添加一个像“next_recurrence_date”这样的属性，它将用于进行一些基本的排序/过滤。您甚至可以使用它将任务放入队列中，以便在下一个重复日期完成某些任务。 （比如检查该日期是否已过，然后重新生成它。您甚至可以在下一个重复日期过去后存储任务的“存档”版本。）

这解决了您的问题“如果任务更新了怎么办”，因为任务不是“我从来没有坚持过，直到它们成为过去。

不管怎样，我希望这对那些试图为自己的应用程序思考这个问题的人有所帮助。

Answer 2

为内部社交网络应用程序完成了类似日历的组件后，这是我解决该问题的方法。

一点背景知识：我需要为整个公司预订董事会会议室。每个董事会会议室都需要一次性或定期预订。正如您所发现的，是重复规则杀死了您。我的问题的另一个问题是可能会发生冲突，即两个人可能会尝试在同一日期和时间预订同一会议室。

我将模型分为会议室（显然）和活动（这是与用户关联的预订）。我认为也有一个加入模型，但已经有一段时间了。当用户尝试预订会议室时，所采取的过程如下：

1. 进行预订（用户通过日历 UI 完成，类似于 Google 日历创建事件的方式）。
2. 尝试在第一个可用日期 ；
3. 如果是重复性活动，请尝试根据给定的规则（每周、每两周、每月）立即预订接下来的 6 个活动 如果由于冲突而失败，请预订您可以预订的预订，将冲突通过电子邮件发送给用户
4. 预订下一年或直到重复在后台作业中结束的日期；遵循 #3 中的冲突解决规则

解决冲突时，用户可以选择根据具体情况解决冲突，或将剩余预订移至新的可用日期和时间。

如果用户更新了原始预订（例如更改了时间和日期），他/她可以选择仅更新该预订或每个后续重复预订。如果选择后者，则在删除现有事件后重新调用步骤 3 和 4。

如果这听起来很像 Google 日历，那么您已经完全理解了我的方法，:)

希望这会有所帮助。

Answer 3

我个人认为（在我熟悉的Python中）和Ruby（我不太了解，但它是一种动态语言，所以我认为概念图1：1），你应该使用生成器。简约的答案怎么样？现在，当您生成 UI 时，您可以传入对生成器的引用，它会根据请求生成您需要的对象。

作为一个接口，它具有下一项和上一项方法，并且行为有点像光标，可以在各种交互中向前和向后移动。事实上，它是一段伪装成无限系列（数组）的代码，而不使用无限内存。

为什么需要增殖对象？您真正需要的是虚拟数据显示控件（用于网络或桌面），我认为在网络环境中也称为“分页”，您可以将您的日程安排视为无限的按需生成的电子表格，没有顶行，并且没有底行。您需要能够计算（计算，而不是存储）的唯一值是当前显示的值，对用户可见。