Question

我正在开发一个应用程序，它将跟踪与我的工作地点有关的医生的各种信息。我们正在跟踪的一件事是，它们可以按一天中的每一天（早上，下午和晚上）的可用性（星期一 - 星期日）。此外，我们将存储关于从业者可用性的可选评论，例如“在满月期间不起作用”。

此信息的输入/显示表单将包含一周中的星期几作为列标题，以及一天中的时间作为行标题。复选框将指示从业者是否在指定时间内可用。

我很难弄清楚如何将这些信息存储在数据库中。创建一个包含24列的表的最明显的解决方案（21天为7天* 3次，1为主键，1为外键引用从业者，1为注释）。这是一个糟糕的表，但至少它很容易选择和更新。

另一种解决方案是创建一个包含属性的表：

practitioner_id :: int（外键和主键）
day_of_week :: int（主键）（也可能是Enum，但我不认为SQL Server有那种类型）
morning :: bit
下午::位
晚上：位

这是一个不那么难看的表，但更新会很痛苦，因为我必须为一周中的每一天都有一个单独的更新声明。评论也必须存储在此表之外。

另一种解决方案可能是每周的每一天都有一列，数据类型为BLOB（或者SQL Server的任何版本）。然后将时间信息存储为三个数组。但我确信这打破了良好数据库设计的每一条规则。这也会限制选择查询的有效性。

有关如何存储此数据的任何想法？

编辑：

为了澄清，我们只关心他们的平均周时间表。假期和假期等事情都可以忽略不计。

在前端，信息将显示为网格，列表示星期几，以及表示当天时间的行。

此信息可能需要搜索。例如，我们可能想要提供周一晚上工作的所有从业者的报告。

Answer 1

我建议采用以下设计，多对多关系。

table: practitioners
- practitioner_id

table: schedule_blocks
- schedule_block_id

table: practitioners_to_schedules
- practitioner_id
- schedule_block_id

当我设计时，我正在使用查看系统的生命周期以及可能添加的更改内容。这种设计需要先付出更多的努力，但随着时间的推移可以节省成本。

只有从业者可用时，记录才会写入Practers_to_schedules表。这可能会减小表的大小，并可能导致每个数据/索引页的记录数量更多。

上述设计的一个优点是它不会将当前调度“分块”硬编码到模式中。如果在将来，系统将“块”分解为几个小时，表模式将不会更改，只会更改表的内容。

另一个优点是，它适用于有效日期的概念。每周一早上都有医生，但下周不在。将effective_date和end_date添加到关系表中，并支持该功能。

这适用于相对简单的索引方案。从业者_to_schedules的两个索引，您可以有效地报告大多数选项。根据最常见的读取，您可以决定使用哪个ID作为聚簇索引。

Answer 2

听起来您的第二个桌面设计可以更好地满足您的需求：

practitioner_id :: int (foreign key and primary key)
day_of_week :: int (primary key)
morning :: bit
afternoon :: bit
evening :bit

如何在SQL Server中存储从业者（一周中的某一天和一天中的时间）的可用性

2 个答案: