Question

对于这个应用程序，工作人员需要能够在他们开始时进行设置＆amp;结束一周中的每一天。他们可以选择每1,2或4周开始/结束一次。例如，我在上午9点开始工作，每周一下午2点结束。有了这样简单的重复，我想有3个，也许2个模型（用于非规范化）：

Event
  - start: datetime
  - end: datetime
  - type: int (appointment, time off, cancelled, etc)
  - date: date (useful?)
  - staff_id: int
  - customer_id: int
  (more, redacted)

DayTemplate
  - active_start: datetime
  - active_end: datetime
  - staff_id: int

Day
  - weekday: int
  - start: datetime
  - end: datetime
  - recurrence: int (0: none, 1: once/mo, 2: other week, 4: every week)
  - day_template_id: int

这个想法是现在已经设置了参数，所以客户可以在有空的时候进入并预订员工（在特定的块中，比如上午9点，上午10点15分，11点30分 - 以允许休息时间建立）。对于日程安排中的任何一天，您可以轻松查询该员工活跃的DayTemplate。然后，工作人员可以通过将事件预订为“休息时间”来进一步调整时间表，以便对其进行微调控制。另外，我在考虑将Day解压缩为DayTemplate - 我知道它会看起来很难看，但架构永远不会改变，性能优势会让它值得吗？这有足够的灵活性吗？

感谢您的反馈。我将在rails中构建它。

Answer 1

对于这个应用程序，工作人员需要能够在他们开始时进行设置＆amp;结束一周中的每一天。他们可以选择每1,2或4周开始/结束一次。例如，我在上午9点开始工作，每周一下午2点结束。有了这样简单的重复，我想有3个，也许2个模型（用于非规范化）：

不要反规范化。专注于获取业务规则，然后将这些规则映射到rails中的业务对象。让架构设计由特定的应用程序需求驱动。

此外，我正在考虑将Day解压缩为DayTemplate - 我知道它看起来很难看，但架构永远不会改变，性能优势会让它值得吗？

当然，您不应该担心优化性能。而是为了清晰和简单而优化。机会是你的应用程序需要性能优化的方面将与你预先猜到的完全不同。

这有足够的灵活性吗？

也许太多了。我建议你尽可能地建立最符合最低验收标准的东西。不要试图灵活地进行工程设计，因此很难预测需要什么样的灵活性。随着时间的推移，维护所有这些“可能 - 我们将需要 - 这一天”功能的成本将阻碍您构建真实用户真正想要的东西。这是违反直觉的，但现在保持尽可能简单是最好的方式，最终得到一个真正功能丰富的系统。优化交付速度，将其交付给真实用户并开始收集反馈。

此外，构建任何类型的调度系统的事情是复杂性很快就会失控。如果你正在做这个练习，那么尝试自己编写代码可能是值得的，但如果这是你真正需要认真做的事情，请考虑使用众多ruby宝石中的一个来帮助建模/安排重复事件。我个人使用ice cube，但the ruby toolbox

有很多选择

提出的简单调度/可用性数据库模式

1 个答案: