Rails 和 Postgresql 中的每周小时分配问题答案

【问题标题】：Weekly hour allocation problem in Rails and PostgresqlRails 和 Postgresql 中的每周小时分配问题
【发布时间】：2019-06-11 09:14:30
【问题描述】：

如果我有一个具有特定日期范围的任务列表，并且该任务被分解为每周小时的工作块（即从 2018 年 12 月 31 日到 2019 年 1 月 6 日的 30 小时......等从星期一）。

我想做的操作是

将这些每周记录存储为

会更有效吗

存储开始/结束日期可能会给表格带来更大的灵活性，因为它可能会存储非每周对齐时间。

存储周数意味着给定一个日期范围，创建每周块就像查找开始日期的周数和结束日期的周数一样简单，然后填充其间的周数（无需转换为日期范围） .只要周数为 1-53，更新一周的小时数也更容易验证。

想知道是否有人尝试过任何一个选项并且可以就他们的首选选项给出任何指示。

【问题讨论】：

【解决方案1】：

我可能会选择daterange 专栏。

这使您可以灵活地拥有不同大小的块，并允许您定义 exclusion constraint 以防止重叠范围。

使用“包含”运算符@> 查找给定一周的行仍然非常简单，例如where the_column @> to_date('2019-24', 'iyyy-iw') 查找包含 2019 年第 24 周的行。

表达式to_date('2019-24', 'iyyy-iw') 返回指定周的第一天（星期一）。

也可以找到两周之间的所有行，但是构建相应的日期范围看起来有点难看。您可以使用第一天和最后一天构建一个包含范围：daterange(to_date('2019-24', 'iyyy-iw'), to_date('2019-24', 'iyyy-iw') + 6, '[]')

或者您可以创建一个具有下周第一天的专属上限的范围：daterange(to_date('2019-24', 'iyyy-iw'), to_date('2019-25', 'iyyy-iw'), '[)')

虽然可以非常有效地对范围进行索引，但所需的 GIST 索引的维护成本比两个整数列上的 B-Tree 索引要贵一些。

使用范围的另一个缺点（如果您并不真正需要灵活性）是它们占用的空间比两个整数列（14 字节而不是 8 字节，甚至 4 字节和两个 smallint）更多。因此，如果表的大小有任何问题，那么您当前使用年/周列的解决方案会更有效。

“存储周数意味着给定一个日期范围，创建周块就像找到开始日期的周数和结束日期的周数一样简单”

如果您输入的是开始日期和结束日期（而不是“周数”），那么我肯定会选择 daterange 列。如果该开始日期和结束日期超过一周，那么您只存储一行，而不是多行。

【讨论】：

感谢@a_horse_with_no_name 的详细回复！我认为使用“包含”运算符找到给定周的行很好，但是如果该行的周范围跨越两周，那么如果我想对每一周的每周小时数求和，就会变得模棱两可。如果我想要灵活性，Daterange 是一个不错的选择，但我认为如果我主要使用周块，那么年份 + 周数可能会更简单，而且我确实担心表大小。