0

这是一个独特的问题,但我想我会看看是否有人从经验中有所了解。

需要在 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 是否更适合。或者,如果对整件事有坚如磐石的论据,哈。任何见解将不胜感激。

4

1 回答 1

0

我的系统涉及两个表:

  • 预定事件,例如定期约会以及任何其他义务。
  • 基于规则的重复事件,可以是每天、每周等。其中包括节假日和午休时间发生的规则。

根据提供者或服务进行预约。因此,数据库的时间表表有一个系统,用于对不同类型的事件进行分类,无论它涉及特定的提供者还是特定的服务。如果适用,它还包含每个事件的客户端 ID。

我还为每个提供者准备了表格,以及他可以提供哪些服务。如果提供者在给定小时内可用,则根据他的可用性以及其他提供者的可用性来计算服务的可用性。它还取决于服务的类型。

管理员可以编辑服务的特征:

  • 服务的持续时间。
  • 每单位持续时间每个提供商的客户数量。对于某些服务,它只是一对一的,但其他服务可能会持续一个小时,并且在那一小时内,一个提供商可能能够照顾多个客户。

该系统基于平均工作量。如果服务的特性使提供者超负荷,管理员可以简单地调整数据库中的服务特性以限制安排的约会数量。

我做的另一件事是将时间单位分解为 15 分钟的块(这实际上是一个配置设置,如果需要可以更改)。因此,所有调度和规则都以块开始和结束。我的类中有一组转换函数来转换,例如,在时间戳和块单位之间进行转换,四舍五入到最近的块。

把它们放在一起是一项艰巨的任务。基于 shedules、规则、服务类型等的所有数据,我必须想出给定持续时间的数组来显示提供程序和服务的可用性。例如,对于给定的一周和给定的服务,我的课程必须生成一个数组来显示可以安排在任何时间段的约会数量。为此,我考虑了可以叠加的“透明度”。如果给定服务有 3 个提供商,那么我必须将他们的日程表叠加起来,就好像它们是透明的一样。如果给定的时间段有所有三个提供商都可用,则可以认为透明度对于调度是明确的3 * Serviceload. 然而,根据供应商的不可用,透明胶片会越来越灰。如果所有三个都不可用,则该块将被“涂黑”,因此无法安排约会。

在调度数组中获得所有可用数据后,我将所有数据与 jQuery FullCalendar 类合并以进行拖放调度。

于 2013-07-18T17:26:21.257 回答