在 UI 和数据库中表示时间段答案

【问题标题】：Representing time periods in the UI and database在 UI 和数据库中表示时间段
【发布时间】：2011-06-15 21:48:47
【问题描述】：

我最近采用了一个带有 Employee 模型的项目，该模型需要包含该人的可用时间作为属性。

现有表单使用 168 个复选框来表示一周中的每个小时，并将信息以 7 个 24 位二进制字符串的形式存储在数据库中，每个位作为当天对应小时的布尔值 true 或 false。

我真的很想过渡到更优雅和更易于管理的东西，但我无法提出任何与现有实施灵活性相匹配的简单解决方案。

当每天可能有多个时间段时，将时间段存储为开始时间和结束时间可能同样繁琐，并且可能会使查询特定时间的可用性变得更加复杂。

在用户界面和数据库结构中是否有处理此类信息的最佳实践？

【问题讨论】：

PostgreSQL 原生支持时间间隔作为数据类型。
这绝对是个好消息，但我不确定它是否真的能解决问题。如果我没记错的话，这些间隔与特定的开始或结束时间无关，因此必须将它们用作更复杂的数据结构的一部分来表示所有必需的信息。我想我真正想要的是一种干净、易于管理的方式来输入、存储和查询 168 个布尔值。或者更好的方式来表示一周中的每个小时。
您可以将间隔字段与日期字段配对，这样日期字段将给出开始时间，间隔给出持续时间。不知道这比只有两个日期字段好还是坏；这取决于您想要运行的语义和查询。
大多数查询只是检查用户是否在给定时间段内有空。这种表示可能会变得复杂，因为查询开始时间不一定与属性开始时间匹配。您必须在查询时间之前搜索开始时间，并且持续时间超过查询持续时间。您还必须验证模型中没有重叠的时段。
时间是一个非常讨厌建模的东西。

标签： javascript sql ruby-on-rails

【解决方案1】：

我会以这种方式对数据库中的数据进行建模。

员工与一周中每一天的小时数之间存在多对多关系。

在 UI 方面，您可以使用日期复选框和多选列表框来设置给定日期的小时数。

【讨论】：

这看起来是迄今为止最有前途的方法。最初我对模拟一周中的日子和数字 0 到 23 犹豫不决，但它确实提供了一种更简单的查询可用性的方法。
再想一想，像这样将小时和天数提取到他们自己的表中是否有优势？为什么不能用hour 整数和day 字符串替换hour_id 和day_id？通过适当的验证，它们永远不会具有意想不到的价值，我认为这不会影响该方法的任何灵活性。
我这样做是为了模拟正确的标准化。如果您需要存储有关小时和天的其他描述符，则将有空间存储它。例如，DOW 表可以有一个 int 表示数字日期，一个 Short_Day 表示 Mon、Tue、Wed 等，Long_Day 表示周一、周二、周三等。Hour 可以有 int 小时，然后是 char 表示 12am、1am 等或 12-1am、1-2am 等。这将通过提供各种用于人类可读性的描述符来帮助您的界面。
附带说明，这篇文章：sqlservercentral.com/articles/Stairway+Series/… 今天刚刚发布，涉及处理数据库中的时间数据。在这种情况下可能没有帮助，但仍然很有趣。

【解决方案2】：

你能做个时间段块吗？

Employee
  Availability
    7AM -> 12PM
      Monday
      Tuesday
      Wednesday
    1PM -> 4PM
      Monday
      Tuesday
    1PM -> 5PM
      Wednesday

每个用户都会有一个时间块列表，这些时间块代表一天中的一个或多个小时。每个时间块也可以代表一周中的一天或多天。根据用户可用性的复杂程度，数据可能很少或很多。

如果您不想更改 UI，则无需更改 UI，因为您只需弄清楚选中了哪些复选框并构建一个时间段块即可。如果时间之间有一个或多个小时的间隔，它将成为另一个时间段。

添加 Shift UI :: http://imm.io/6vGk

显示员工轮班 :: http://imm.io/6vGv

【讨论】：

那么在这种情况下，会有一个单独的可用性表，其中包含 start hour、end hour、day 和 user_id 列？这可能会使数据库更易于查看，但我不相信它会使输入或查询更容易。
是的，这可以用于数据库。至于查询，它仅取决于您需要执行的类型，查询越复杂，任何事情都会变得越困难。 UI 可以是您真正想要的任何东西……例如，我将在上面的答案中添加一些图像，以说明我为添加/显示班次所做的工作

【解决方案3】：

我们将员工日程安排和非可用时间存储在两个不同的表格中。搜索正在建立可用时间，然后排除不可用时间。员工日程表的数据结构相当复杂，因为存储每天的日程表只会让我们的搜索变得非常缓慢并且表格很大。

【讨论】：