在日历中重复"事件":CPU与数据库

Question

我正在从头开始构建一个日历系统(要求,因为我正在与Gregorian一起使用特殊类型的日历),我需要一些逻辑方面的帮助.我正在用Django和Python编写应用程序.

从本质上讲,我遇到的逻辑问题是如何在不占用CPU周期选项卡的情况下尽可能巧妙地保留尽可能少的对象.我觉得多态性可以解决这个问题,但我不确定如何在这里表达它.

我有两个基本的事件子集,重复事件和一次性事件.

重复事件将有订阅者,人们被通知他们的更改.例如,如果一个班级被取消或移动到不同的地址或时间,那么订阅的人需要知道这一点.有些事件每天都会发生,直到时间结束,不会被编辑,"只是发生".问题是,如果我有一个存储事件信息及其重复策略的对象,那么取消或修改系列中的一个事件确实搞砸了,我将不得不以某种方式解释这一点,让订阅者意识到这一变化和将系列保持为一个逻辑组.

悖论:为一系列中的每个正常事件生成唯一的事件对象,直到时间结束(如果它无限重复),如果它们都要存储相同的信息,则没有意义; 但是,如果系列中的单个事件发生任何变化,我几乎必须在数据库中创建一个不同的对象来表示取消.

有人可以帮我解决这个问题吗？它真的扭曲了我的思绪,我不能再思考了.我真的很喜欢如何解决这个问题的一些意见,因为重复事件也不是最简单的逻辑事件(每隔一天重复一次,或每个M/W/F,或每个月的第一个M,或者每3个月,或者在这个日期每年一次,或者在这个日期每周一次,或者在这个日期每月一次,或者在星期二的上午9:00和星期四的上午11:00等,并且我会比如帮助理解重复事件的最佳逻辑路线.

以下是关于如何做到这一点的想法:

class EventSeries(models.Model):
    series_name = models.TextField()
    series_description = models.TextField()
    series_repeat_policy = models.IHaveNoIdeaInTheWorldOnHowToRepresentThisField()
    series_default_time = models.TimeField()
    series_start_date = models.DateField()
    series_end_date = models.DateField()
    location = models.ForeignKey('Location')

class EventSeriesAnomaly(models.Model):
    event_series = models.ForeignKey('EventSeries', related_name="exceptions")
    override_name = models.TextField()
    override_description = models.TextField()
    override_time = models.TimeField()
    override_location = models.ForeignKey('Location')
    event_date = models.DateField()

class EventSeriesCancellation(models.Model):
    event_series = models.ForeignKey('EventSeries', related_name="cancellations")
    event_date = models.TimeField()
    cancellation_explanation = models.TextField()

这似乎有点道理,但如上所述,这现在正在破坏我的大脑,所以任何事情似乎都会起作用.(另一个问题和疑问,如果有人想要修改系列中的所有剩余事件,我该怎么做!？!？我想我可以更改'series_default_time'然后为所有过去的实例生成异常实例来设置它们到原来的时间,但是AHHHHHH !!!)

将其归结为三个简单,具体的问题,我们有:

1. 我怎样才能有一系列重复事件,但允许对单个事件进行取消和修改以及对整个系列的其余部分进行修改,同时在数据库中尽可能少地存储绝对必要的对象,从不为单个事件生成对象预先？
2. 如何以高度可定制的方式重复事件,而不会失去理智,因为我可以通过多种方式允许事件重复,但是再次使事情变得简单并尽可能少地存储对象？
3. 我怎样才能完成上述所有操作,允许在每个事件系列中进行切换,以使其在假期失效时不会发生？

Answer 1

我只想解决问题 3，关于假期。

在几个报告数据库中，我发现定义一个表很方便，我们称之为“年鉴”，该表在一定范围内每个日期都有一行。如果范围跨越十年，该表将包含大约 3,652 行。以今天的标准来看，这个数字很小。主键是日期。

其他一些列例如日期是假期、正常工作日还是周末。我知道，我知道，您可以使用内置函数来计算周末的事情。但事实证明，将这些东西作为数据包含进来很方便。它使您的连接更加简单并且彼此更加相似。

然后您就有了一个填充年历的应用程序。它内置了所有日历怪癖，包括确定哪些日子是假期的企业规则。如果与您的情况相关，您甚至可以包含给定日期所属的“会计月份”列。应用程序的其余部分，无论是输入程序还是提取程序，都将年历视为普通的旧数据。

这可能看起来不是最理想的，因为它不是最小的。但请相信我，这种设计模式在多种情况下都很有用。由您决定它如何适用于您的案例。

年鉴实际上是数据仓库和星型模式设计原则的子集。

如果你想在CPU内部做同样的事情，你可以有一个具有公共功能的“Almanac”对象，例如Almanac.holiday(date)。