我知道它几乎被告知与rdbs中的时间表建模有关的任何事情,但是我找不到任何关于可用技术的好的文档来将时间表存储在db中。
我的案子:
我有一张桌子,里面有可用的位置,还有一张有实际班级的桌子。
每个地方都有自己独特的时间表
每节课都可以在任何地点、任何时间安排,只有少数例外:
一个班可以安排一个时间段(例如:如果A班在12:00安排在P1,持续时间为1小时,则A班的下一次出现只能安排在12:00之前或13:00之后,在任何有空闲时间段的地方;禁止在两个地方安排一次A班)
在一个地方,它可以是一个有时间间隔的类
模型应支持调度类的版本控制/历史记录
现在,我如何在sql db中表示这个数据模型?
我并没有准备好使用精确的模式,相反,如果有人能写出可用的建模技术和它们的比较,我会很高兴的,我可以用它们来解决这个任务
例如:对于树结构/层次数据,有文献记载的“改进的预序树遍历算法”,是否有处理时隙的类似算法/技术?
最佳答案
时间表是一个矩阵。在左手边我们有位置。在顶部我们有时间段。位置和时间段的任何给定排列的交集是一个具有类或空的单元格。
要对此进行建模,我们需要一个位置表(实体),它是相当固定的数据。我们需要一个不断增长的时隙表(日期/时间)。我们需要一个表类,它也是非常固定的。最后我们需要一个交集表类时隙位置。这就是魔法发生的地方。这个表有三个外键,一个到类,一个到位置,一个到时间段。它的主键是(location_id,timeslot_id),但它还需要一个唯一的约束(class_id,timeslot_id)。
您在问一个建模问题,但是有几个实现细节需要考虑。它们不会改变逻辑模型,但会影响您使用物理表的方式。首先要考虑的是是否生成所有潜在的时间段,如果是,还要考虑存储的窗口有多大。第二个问题是是否为交集表、类时隙位置存储空条目。
这里没有直截了当的答案:一些数据库产品比其他产品更容易“填补空白”。另外,动态生成缺少的记录可能会对性能造成很大影响,在这种情况下,磁盘空间是一个很好的折衷方案。
至于存储历史,这大概是为了存储对计划的更改。为此,请使用由触发器填充的单独表(可以使用存储过程,但触发器是行业标准)。不要试图将历史记录存储在主表中。它打破了正常化的模式,引起了各种悲伤。