Martin Fowler在这里定义了一个优雅的对象模型来调度重复任务，它很好地映射到 OO 代码。然而，将其映射到关系数据库模式以实现持久性是很棘手的。
任何人都可以建议一个模式 + SQL 组合来封装他描述的所有功能，特别是在第 11 页的图像中。相交和联合相当明显 - 复杂性在于表示“时间表达式”，它采用可变参数并且必须被解释不同，然后将它们组合成一个“时间集”。
需要明确的是，有很多方法可以表示关系数据库中重复事件的概念。我希望每个人的意见是如何映射这个特定的模型。
一些可能的选择：
序列化参数列表并将结果存储在 varchar() 中不是解决方案，因为该方法可以防止基于集合的查询:)
恐怕这个答案会有很多参考资料和很少的实用代码，自从我上次搞砸这个问题以来已经有一段时间了，但是......
我认为您要在这里混合使用的两种技术是'active databases'和'temporal databases'。
第一个对于评估规则等很有用，第二个对于存储时间数据并在某个记录有效时进行评估很有用。这两个都是相当大的研究领域，但是你可以用普通的 SQL 来做大部分的时间工作（只要你的数据库有很好的时间支持）。SQL 中的活动部分更难，但PostgreSQL至少有一些规则来帮助解决这个问题。我不了解其他数据库，但它们中的大多数都具有规则/触发器/约束支持，可以转换为您正在寻找的内容。
活动数据库是可以对使用规则存储的事实的变化做出反应的数据库。这些规则是用特定于实现的语言指定的，但对于日常讨论事件-条件-动作规则（ECA 规则）是常见的。有关活动数据库系统的介绍，请阅读文章活动数据库管理系统宣言和活动数据库系统。有关 ECA 规则的更多信息，请查看逻辑事件和 ECA 规则（页面顺序为 o_0）和活动面向对象数据库系统中的事件。
事件处理是规则处理的一个特例，处理如何处理复合事件并适当地触发它们的动作。关于这方面的一个有趣的读物是Active Databases 的复合事件：复合事件检测器的语义、上下文和检测和剖析。另请参阅复杂事件处理站点和事件流处理和复杂事件处理维基百科文章。
时态数据库可以看作是一个可以理解时间的数据库，特别是两种特定的时间；有效时间和交易时间。记录的有效时间是该记录有效的时间段，记录的事务时间是它存在于数据库中的时间。作为一个很好的实用介绍，我推荐Richard T. Snodgrass撰写的关于如何在 SQL 中创建时态数据库的书： Developing Time-Oriented Database Applications in SQL。
另外，您可能想了解的有关时态数据库的所有信息都可以在Springer 数据库系统百科全书的时态数据库条目中阅读，这是一个非常全面的文档（我将从“时态数据库”条目开始），但要开始快一点，查看更易于浏览和阅读的Temporal Database Glossary ，以及网站Time Center，其出版物部分具有（或确实具有...）该地区最著名的出版物的链接。
因此，既然您已经了解了这一切，您很快就会看到第 11 页上的图像可以表示为复合事件，并且可以这样检测/评估，前提是您已经实现了复合事件检测器的正确所需子集，并且rest 可以表示为具有时间方面的表中的条目:)
Martin Fowler 在他的“随时间变化的事物的模式”中解决了大部分问题，总结了许多与时间打交道的模式。
最后，我可能会为时间信息创建一个数据库模式，并为活动部分使用数据库规则或在应用程序中实现该部分（尽管有龙）。如果您使用 PostgreSQL，规则机制在文档的规则系统部分中进行了描述。
有很多要读的，但如果你彻底理解了这一切，你的职业净资产会上升很多:)
此外，谷歌的好词是“时间数据库”、“活动数据库”、“ECA 规则”。
SQL 是一种用于查询数据集的语言。它不容易支持域特定逻辑操作的编码。换句话说，“要评估的规则”不是 SQL 中的数据类型。这是一个面向对象的概念，数据和逻辑都是对象实例的组件。
所以我想说你在 SQL 范式中最多可以做的就是存储 365 行，对应于一年中的日子，以及相应日期是否满足循环计划标准的真/假值。因此，您必须使用实现 Fowler 模型的 OO 逻辑来进行计算，并存储生成的 365 行。
那么什么时候你需要知道“今天（或任何给定日期）是否是日程的一部分？” 查找适当的行并检查真/假列非常容易。对于任何数据库来说，每年存储 365 行都是微不足道的。
这看起来像是作弊，但就像我说的，SQL 是关于数据集，而不是逻辑。