这是一个独特的问题,但我想我会看看是否有人从经验中有所了解。
需要在 Web 应用程序中存储呼叫中心员工的每周计划。Web 应用程序具有三个实体:
员工 - 属于组
员工组 - 包含员工,具有适用于添加到组的新员工的基本时间表
管理员 - 负责维护员工组。举例来说,管理员也可以是雇员。
要求
管理员可以更改员工组的基本计划
管理员可以选择允许员工偏离计划,由管理员控制
管理员可以进一步选择允许员工自己偏离计划
管理员使用 UI 小部件来确定员工组的日程安排。时间表分为三种类型,按一般可怕程度 ASC 排序
- 类型 1 - 24/7 可用性(将其表示为时间表上的一个简单标志与标记周一至周日完全可用性)
- 类型 2 - 设置的开始/结束时间,或选定日期的一组开始/结束时间。(例如 9a-11a、1p-4p、周一至周五)
- 类型 3 - 一组可变的开始/结束时间,随天而变(例如 9a-12p、Mon、1p-4p、5p-9p、Tue 等)
管理员可以通过 UI 随时更改计划类型
允许偏离的员工也可以随时通过 UI 更改日程类型
查找必须快速,因为我们必须访问单独的数据库以获取有关可用员工的更多信息
为了更好地衡量,需要相对于调用者时区计算可用性。因此,有可能 EST 中具有类型 2 时间表的组实际上可能不可用,具体取决于呼叫者从何处发出呼叫
我确实说服他们允许我们在原始时间表无法根据 UI 要求轻松转换为新时间表的情况下删除时间表条目。最好的例子是 Type 3 -> Type 2。
但是,昨天(截止日期前 3 个工作日)提出了一项附加要求,即对于类型 3,用户必须能够指定跨越午夜的时间范围。例如:
Start [Monday] at [9:00pm] until [Tuesday] at [3:00am] [Add new time block]
Start [Tuesday] at [8:00am] until [Tuesday] at [5:00pm] [Add new time block]
当通过 Type 3 UI 进行更改时,还需要在合并时自动检测计划重叠和邻接。
在给定时间、星期几和 group_id 的情况下,应该有助于快速查找的示例模式
employee_schedule
_________________
id (int) auto-inc // PK
employee_id (int) // FK
employee_group_id (int) // FK
start_day (int) // 0-6
start_time (time)
end_day (int) // 0-6
end_time (time)
但是,鉴于您不能信任用户输入,用户界面(至少对于类型 3)使添加/编辑/更新变得单调乏味。
有没有人遇到过类似的问题?我试图弄清楚我是否应该做一堆前端验证来检测重叠/邻接并在将它们发送到服务器之前合并它们,或者 PHP 是否更适合。或者,如果对整件事有坚如磐石的论据,哈。任何见解将不胜感激。