这里有一个独特的问题，但我想我会看到是否有人从经验中得到了一些洞察力。
需要在Web应用程序中存储呼叫中心员工的每周计划。 Web应用程序有三个实体：
员工 - 属于团体 员工组 - 包含员工，具有应用于添加到组的新员工的基本计划 管理员 - 负责维护员工组。为了示例，管理员也可以是员工。
要求
管理员可以更改员工组的基本计划
管理员可以选择允许员工偏离 时间表，由管理员控制
管理员可以进一步选择允许员工偏离计划 他们自己
管理员使用UI小部件来确定员工组的计划。时间表有三种类型，按一般可怕性ASC
排序管理员可以随时通过UI
允许偏离的员工也可以随时通过用户界面更改计划类型
查询必须快速，因为我们必须进入单独的数据库以获取有关可用员工的更多信息
为了更好地衡量，需要相对于来电者时区计算可用性。因此，具有类型2时间表的EST中的组可能实际上不可用，具体取决于呼叫者从哪里拨打电话
我确实把它们说成是允许我们在原始计划无法根据UI要求轻松转换为新计划的情况下，将计划条目分开。最好的例子是Type 3 - ＆gt;输入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而言，UI会使得添加/编辑/更新练习变得乏味，因为您无法信任用户输入。
有没有人遇到过类似的问题？我试图弄清楚我是否应该做一堆前端验证来检测重叠/邻接并在将它们发送到服务器之前将它们合并，或者如果PHP更适合。或者如果对整个事情有坚如磐石的争论，哈哈。任何见解都将不胜感激。
答案 0 :(得分：0)
我的系统涉及两个表：
根据提供者或服务进行预约。因此，数据库的shedule表具有用于对不同类型的事件进行分类的系统，无论是涉及特定提供者还是特定服务。如果适用，它还包含每个事件的客户端ID。
我还为每个提供商提供了表格，以及他可以提供哪些服务。如果提供商在给定时间内可用，则根据其可用性以及其他提供商的可用性计算服务的可用性。它还取决于服务类型。
管理员可以编辑服务的特征：
系统基于平均工作量。如果服务的特征使提供者超载，管理员可以简单地调整数据库中的服务特征，以限制预定的约会数量。
我做的另一件事是将时间单位分解为15分钟的块（这实际上是一个可以根据需要更改的配置设置）。因此，所有调度和规则都以块开始和结束。我的类中有一组转换函数，例如，在时间戳和块单位之间进行转换，四舍五入到最近的块。
将所有这些放在一起是一项非常重要的任务。基于所有数据，规则，服务类型等，我必须在给定的持续时间内提出数组，以显示提供者和服务的可用性。例如，对于给定的一周和给定的服务，我的类必须生成一个数组来显示可以为任何时间段安排的数量约会。为此，我想到了可以叠加的“透明度”。如果给定服务有3个提供者，那么我必须将他们的时间表覆盖为透明度。如果给定的时间段有所有三个提供者可用，则可以认为透明度对于安排3 * Serviceload是明确的。但是，根据提供商的不可用性，透明度会越来越灰。如果所有这三个都不可用，则该块将被“遮挡”，以便不能安排任何约会。
在调度数组中提供了所有数据后，我将其全部与jQuery FullCalendar类合并，用于拖放调度。