我应该如何（你会如何）将时间表保存在数据库中

Question

我有一个应用程序，用户可以在其中设置特定日期范围内特定实体的时间表。日程编辑与输入日历约会类似：

• 何时开始和何时结束（小时）
• 开始日期并设置每周重复天数（即每个星期六和星期日或仅每个星期五）
• 重复周期结束日期 - 设置重复周期结束的日期

例子

我想将 2011 年 1 月的周末日程安排为上午 7 点至下午 5 点。

1. 我将开始日期设置为 1.1.2011
2. 将结束日期设置为 31.1.2011
3. 我设定7:00开始，17:00结束
4. 启用每周重复掩码上的星期一

然后我还会输入一个与现有时间表重叠的新时间表，但仅适用于一月上半月：

1. 设置开始日期 2011 年 1 月 1 日
2. 设置结束日期 2011 年 1 月 14 日
3. 设定时间9:00至15:00
4. 周一启用。

问题

我可以将每天的时间表存储在一个表中，例如：

create table EntitySchedule (
    EntityID int not null
        references Entity(EntityID),
    ForDay date not null,
    StartAt time not null,
    EndAt time not null
)

但我会在这个表中得到很多记录：

每个计划的记录数=（实体记录数）*（计划范围内的天数）

或者我可以存储类似于输入数据的数据：

create table EntitySchedule (
    EntityID int not null
        references Entity(EntityID),
    StartRange date not null,
    EndRange date not null,
    StartAt time not null,
    EndAt time not null,
    WeekdayMask tinyint not null -- bitmask of days (7 bits)
        default (0)
)

该表的记录比前一张表少很多。

比较

它们中的每一个（按天表和按时间表）都有其优点和缺点：

1. 每天的表格很容易获得特定日期的时间表
2. 每天的计划无法编辑重复数据，您始终会输入一个新的计划来覆盖现有数据
3. 几年后，每天的表将包含大量记录，必须减少这些记录
4. 如果按时间表表获取特定日期的时间表，则无需计算就不可能
5. 每个计划表允许将计划从一个日期范围复制到另一个日期范围，这将是一项非常受欢迎的功能，只需从不同的日期范围导入计划数据并将其应用到新的日期范围，即可使创建计划变得简单。

使用场景

不要将其视为我们从个人日历中得知的平常日历约会。而是将其视为非常灵活的商店/商店（实体）营业时间（时间表）。因此，我的数据库将包含许多商店，并且它们的营业时间非常灵活，通常每周重复一次。

编辑时间表通常是覆盖现有数据，因此当定义的日期范围内的开放时间已经存在时，我们不会真正更新现有的时间表定义，而是创建一个新的时间表定义来覆盖现有的时间表定义。如果有每天的时间表，这非常简单。我只是覆盖适用于新计划日期范围的那些日子。

但对于每个调度表来说，这变得更加复杂：

1. 我可以在表中插入一条新记录，然后在读取特定日期的时间表时最新记录获胜（一种后进先出方法）。这意味着每个计划读取（选择）将包括一个更复杂的查询，其中我必须返回与定义正确范围内的日期的特定实体相关的所有记录，然后返回最后一个。这对于获取特定日期的日程安排来说很好，但是当我想要某个日期范围的日程安排时，这会让我的生活变得困难......
2. 定义的计划范围不重叠，当我插入一个新的计划范围时，这也可能意味着现有的计划定义（或其中许多）应该更改，甚至分成两个。

第一个似乎是更好的方法。但是获取日期范围的时间表的查询变得相当复杂，并且可能不是很快。想象一下获取 2011 年 1 月的实体时间表。读取数据应始终以每日表格的形式生成结果。

问题

有没有保存时​​间表数据的标准方法？您建议我如何保存这些数据？

Answer 1

我曾多次与这个问题作斗争。我认为最好的方法是简单地将开始日期/时间和结束日期/时间存储为开始和结束的单个字段，或者按照您的建议存储为日期和单独的时间字段。

我认为这是最灵活的，尽管它需要在应用程序层进行更多计算以实现重叠的时间表等，但它是所有替代方案中“最不坏”的。但我不确定这是标准方式。

附：我曾经实现过一个系统，其中一年中的每一天都有一个表中的记录，并且一个单独的表存储了当天使用的所有时间表，但它变得比它的价值更麻烦，因为它还需要在应用程序层上进行大量编码，但在不同的地方。我认为使用日期/时间是最好的解决方案。