2

对于此应用程序，员工需要能够在一周中的每一天开始和结束时进行设置。他们可以选择每 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 中构建它。

4

1 回答 1

1

对于此应用程序，员工需要能够在一周中的每一天开始和结束时进行设置。他们可以选择每 1、2 或 4 周重复一次开始/结束。例如，我每周一早上 9 点开始工作，下午 2 点结束。通过像这样的简单重复，我正在考虑拥有 3 个，也许是 2 个模型（用于非规范化）：

不要去规范化。专注于降低业务规则，然后将它们映射到 Rails 中的业务对象。让架构设计由特定的应用程序需求驱动。

此外，我正在考虑将 Day 非规范化为 DayTemplate - 我知道它看起来很难看，但架构永远不会改变，性能优势是否值得？

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

这足够灵活吗？

也许太多了。我建议尽可能构建满足最低验收标准的最简单的东西。不要尝试设计灵活性，很难预先猜测需要什么样的灵活性。随着时间的推移，维护所有这些“也许我们有一天会需要”功能的成本将阻碍您构建真正用户真正想要的东西。这是违反直觉的，但现在让事情尽可能简单是最好的方式，最终得到一个真正功能丰富的系统。优化交付速度，将其交到真实用户手中并开始收集反馈。

此外，构建任何类型的调度系统的问题在于其复杂性很快就会失控。如果您将此作为练习进行，那么尝试自己编写代码可能是值得的，但如果这是您确实需要认真完成的事情，请考虑使用旨在帮助建模/调度重复事件的众多 ruby​​ gem 之一。我个人用过冰块，但红宝石工具箱有很多选择

于 2013-01-24T05:12:24.443 回答