ruby-on-rails - 在 Rails 中构建预约系统

Question

我希望构建一个具有以下特征的预约应用程序:
- 用户可以是服务提供者或购买者
- 服务提供商设置他们的可用性(但最多只能提前 6 个月设置他们的可用性)
- 然后买家可以根据这些可用性进行预约 - 每次预约，根据服务类型，需要不同的时间
- 根据买家选择的约会，根据服务所需的时间显示一组不同的可用性

我构建的是以下内容:
- A TimeSlot我基于 start_time 创建了许多通用的 30 分钟时间段的模型和 end_time属性。为了使这些时间段延长到 future 6 个月，我每天都在运行一个后台作业来创建所有必要的新时间段

class TimeSlot < ActiveRecord::Base
  has_many :user_time_slots
  # ... more methods below
end

- A UserTimeSlots基本上代表他们可以设置的服务提供商的可用性的模型。因此，当他们创建 user_time_slot 时，他们实际上是在说他们当时可用。

class UserTimeSlot < ActiveRecord::Base 
    belongs_to :time_slot
    belongs_to :service_provider, :class_name => "User"
    belongs_to :appointment
end

- 安 Appointment具有许多 user_time_slots 的模型。它有很多，因为约会属于需要一定时间的服务(服务上的 time_required 属性)并且它可能跨越一个数字 连续 user_time_slots。

class Appointment < ActiveRecord::Base
  has_many :user_time_slots
  belongs_to :buyer, :class_name => "User"
  belongs_to :service_provider, :class_name => "User"
  belongs_to :service
end

- A Service具有许多约会并属于创建该服务的服务提供商的模型。

class Service < ActiveRecord::Base
  has_many :appointments
  belongs_to :service_provider, :class_name => "User"
end

这个领域模型有效；但是，由于以下原因，我想知道是否有更好的方法来做到这一点:

每天使用后台作业在我的后端创建 TimeSlot 记录对我来说似乎有点笨拙 - TimeSlots 的唯一目的是拥有开始和结束时间，然后与之关联。

一旦用户(买方)选择了他们想要的服务，我不确定如何有效地找到 x 个连续的、因此可用于预订约会的 user_time_slots(例如，如果我有 30 分钟的时间间隔)并且用户选择了一个需要 3 小时的约会，我必须找到 6 个连续的时间段)。例如，如果用户单击某个服务的实例，我将必须 1) 获得该服务所需的时间(很容易做到)和 2) 我必须找到该用户的所有 user_time_slots 并收集它们相关的time_slots，然后将每个时隙的开始和结束时间相互比较以找到连续的。这对我来说似乎是太多的迭代，似乎这会使我的应用程序陷入困境!

有没有人有更好的方法或解决方案来做到这一点(特别是围绕寻找连续时隙的主题)？

Answer 1

看起来像一个有趣的项目。 :)

我个人不会模拟“现有时间”，即我不会有后台工作创建“空”数据。

我会尝试这样的模型:



User表在哪里？

我不会为两种不同的用户类型使用共享用户模型。我的直觉是，如果不是现在，随着时间的推移，他们需要变得与众不同。在我看来，它还使模型更加清晰。如果有登录名或任何身份验证，我会为该特定数据添加一个用户表，而不是让服务提供者和消费者与此有某种关系。

服务提供商管理可用性

服务提供者只需要一个空的日历(或类似的)，只列出她已经输入的服务可用性，每个服务。

消费图书预约

消费者将根据服务搜索/浏览/导航服务可用性

根据业务逻辑，即消费者是否总是安排整个定义的时间段？或者消费者可以预订首选时间段。只要预订的时段在给定服务的可用时段内？

排类

所以我们只在服务提供者管理她对特定服务的可用性时才放入服务可用性记录。 Empty 被简单地视为不可用。

我们仅在消费者预订服务时根据服务可用性放入约会记录。

如果消费者只能预订服务可用性时间段的一部分，我建议为剩余的时间创建两个(或一个)新的服务可用性记录。可以通过比较服务可用性和约会来检查时间是否可用，但这不是最佳的。
更好的是只查询特定服务的服务可用性并获取可用性计划，其中没有记录意味着没有可用性。

这里有很多 if，具体取决于您的特定需求和请求的业务逻辑。但我希望这有助于一些灵感和想法。