这与我的上一个问题相似，但它更归结为问题。
我正在设计一个系统来安排任务；大多数时候重复的任务。例如，用户可以将“扫地”安排在每周的周一、周三和周五进行。
我可以从日程表中判断一项任务是否应该在任何特定的日子完成，最重要的是我可以判断它是否应该在当天完成。然后，我必须向工作人员显示当前任务的列表（并将其发送到站点周围的手机）。
然后用户表明他们已经开始了任务（所以我们需要一个状态Task-Started）以及他们何时完成了一项任务（Task-Worked）。如果工人没有很好地完成工作，检查任务的人可以“失败”它，进入结束状态任务失败。一个任务也可以有其他一些状态，但这对于这个问题的范围来说应该足够了。
我想知道是否应该在数据库中创建每个任务发生的实例，从而允许我针对该任务的特定实例存储状态。我想另一种看待它的方式是我在数据库中创建“到期”的初始状态，或“今天到期”以及它到期的实际日期时间（或至少是机会窗口的日期时间）做任务）。
但是-无论如何，这种状态总是可以派生的，因为这是我从中生成“今天的”任务列表的地方，所以它确实感觉像是一个规范化错误——感觉就像我在重复无论如何都可以派生的数据。
优点：
它将允许生成的“到期”任务具有准确的日期时间，从而保护它免受只会影响未来几天的时间表的更改（尽管授予我的 Schedule-History 表允许我获取旧数据）。
可以调整特定日期的日程安排，以防当天发生异常情况。
它在数据库中创建了一个正式的状态，而不是派生它（我只是编造的吗？）。
缺点：
- 它需要一个后台进程来生成这些实例（或生成“Due”或“Due-Today”状态，具体取决于您如何看待它）。
我想我的问题归结为：
1) 如果日程表只是一个确切的日期时间列表，则没有问题，因为每个条目都描述了任务本身。事实是：这个日期时间的这个任务。一旦该任务完成，我们就会针对它存储事实。
2）然而，重复计划只是描述了每个任务应该在什么时候，而不是描述实际发生的情况。
我希望这有点道理。想法？