这是一个相当绊脚石。警告：以下不是问题，而是对我提出的问题的解释。我的问题是 - 你有更好的方法吗？是否有一些我不熟悉的常用技巧？似乎这是一个微不足道的问题。
所以你有任务模型。您可以创建任务，完成任务，销毁它们。然后你有重复的任务。它就像常规任务一样，但它附有一个重复规则。但是，任务可以无限期地重现 - 您可以在计划中提前一年，并且您应该看到任务显示出来。
因此，当用户创建定期任务时，您不希望在未来的一百年内构建数千个任务，并将它们保存到数据库中，对吗？所以我开始思考 - 你是如何创造它们的？
一种方法是在查看日程安排时创建它们。因此，当用户提前一个月移动时，将创建任何重复任务。当然，这意味着您不能再简单地处理任务的数据库记录。您执行的任务上的每个SELECT操作都必须位于特定日期范围的上下文中，以便触发该日期范围内的重复任务。这是一种维护和性能负担，但可行。
好吧，但原来的任务怎么样？每个周期性任务都与创建它的重复规则相关联，并且每个重复规则都需要知道开始重复的原始任务。后者很重要，因为当用户浏览他们的日程安排时，您需要将原始任务克隆到新日期。我猜也是可行的。
但是如果原始任务更新会发生什么？这意味着，当我们浏览计划时，我们将创建从修改的任务克隆的重复任务。那是不可取的。所有隐式持久的重复任务都应该显示添加重复时原始任务的样子。因此，我们需要单独存储原始任务的副本，并从中进行克隆，以便重复工作。
但是，当用户在计划中导航任务时，我们如何知道在特定点是否需要创建新的重复任务？我们问复发规则：“嘿，我今天应该继续执行任务吗？”它说是或否。如果今天已经有这个重复的任务，我们不会创建一个。一切都很好，除了用户还应该能够简单地删除一个自动持久的重复任务。在这种情况下遵循我们的逻辑，系统将重新创建已删除的任务。不好。因此，这意味着我们需要继续存储任务，但将此标记为已删除的任务以便再次发生。咩。
正如我在开始时所说，我想知道其他人是否解决了这个问题并且可以在这里提供建筑建议。它必须是这个混乱吗？有什么比我更缺的优雅吗？
更新：由于这个问题难以完美回答，我将批准对设计/架构最有帮助的见解，这对于此类问题具有最佳的帮助/权衡比率。它不必包含所有细节。