Question

我正在为许多员工设计一个调度系统，让他们全天候在家工作。当用户安排新事件（1小时长事件，从小时开始，24小时选择）时，系统需要允许我们的用户选择他们想要为他们工作的员工。我需要在那个确切的时间报告谁可用。我们有超过100名员工，他们的可用性经常变化。

日程表：
EventID EmployeeID startTime (datetime) endTime (datetime)

可用性表：
EmployeeID 00:00 01:00 02:00 03:00 ... 23:00

可用性表中的记录存储为varchar（7）。长度为7是一周中的每一天。此时间段从未提供过'0000000'。该时段始终可用的是'1111111'。该时段仅在周二提供，为'0010000'。

编辑：此信息为一周，因此为7个字符长度。从本周到无限，此表设计假定员工每周可以在同一时间使用（除非他们正在工作）。当然，员工可以更改其可用性，然后该表可以反映从那一点开始的那些变化。的 /修改

在任何给定时间找出员工可用的东西需要大量的循环，这显然会使系统陷入困境，对任何人都不利。

这是我实现此系统的最佳方式，缺少可能有一个表来存储每个员工的可用性。我意识到我的方法很可怕。有人可以指点我正确的方向吗？

Answer 1

我认为你可能最好存储每个用户的可用性，实际上并不是那么多数据，而且一旦传递就可以使它过期。：

create table employee (
  `id` TINYINT(3) UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT
);

create table `employee_availability` (
  `id` INT(10) UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
  `employee_id` TINYINT(3) UNSIGNED NOT NULL, KEY `employee`(`employee_id`),
  `start_time` DATETIME, KEY `start`(`start_time`),
  `end_time`   DATETIME, KEY `end`(`end_time`)
);


SELECT e.* FROM employee
  JOIN employee_availability ea ON ea.employee_id = e.id
WHERE NOW() between start_time and end_time

Answer 2

有一个不同的表来存储员工的可用性。我不明白为什么你不应该这样做。

您应始终避免将多个数据字段放在一列中（作为varchar列）。我建议每个员工，时段和日一行。这样，您可以通过编制索引来大大加快查询速度。

即使如果你保持丑陋的“一切一列的方法”你应该改为CHAR，因为现在你每行使用一个字节只是为了保持大小专栏，即使它总是7个字符长。或者甚至更好，使用TINYINT（1字节）并将可用性存储为二进制标志。但当然，不惜一切代价避免这种情况 - 你真的想要normalize你的数据库。

每周员工可用性数据库设计

2 个答案: