6

我正在寻找具有以下特征的预约应用程序: - 用户可以是服务提供商或买家 - 服务提供商设置他们的可用性(但只能将他们的可用性设置为最多提前 6 个月) - 然后买家可以基于预约关于这些可用性 - 每个预约,根据服务类型,需要不同的时间 - 根据买家选择的预约,根据服务需要多长时间显示一组不同的可用性

我已经构建了以下内容: - 一个TimeSlot模型,我在其中创建了许多基于 astart_timeend_time属性的通用 30 分钟时间段。为了使这些时间段延长到未来 6 个月,我每天运行一个后台作业,创建所有必要的新时间段

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

- 一个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

-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,然后将每个时间槽的开始和结束时间相互比较以找到连续的时间。这对我来说似乎迭代太多了,而且这似乎会使我的应用程序陷入困境!

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

4

4 回答 4

13

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

我个人不会对“现有时间”进行建模,即我不会让后台作业创建“空”数据。

我会尝试这样的模型:

在此处输入图像描述

User表在哪里?

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

服务提供商管理可用性

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

消费者预约预约

消费者将搜索/浏览/导航服务可用性,每个服务

取决于业务逻辑,即消费者是否总是安排整个定义的时间段?或者消费者可以预订一个首选的时间段。只要预订的时段在给定服务的可用时段内?

调度

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

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

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

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

于 2015-05-30T09:06:05.247 回答
6

对于每个可用期,我都会有一个模型。每个时期都有一个start_timeend_time。他们可以很容易地验证不超过提前 6 个月,您可以检查约会是否合适。您的时间段不需要属于这样的约会;约会将简单地具有时间和服务提供者,并且所述服务提供者的可用性将改变以反映预订的约会。

class AvailabilityPeriod < ActiveRecord::Base 
    belongs_to :service_provider, :class_name => "User"
    validates :end_time, :inclusion => { :in => Time.now..(Time.now + 6.months) }

end

例如,您可以找到给定服务和提供者的所有可能可用性,如下所示:

duration = @service.duration
available_times = @provider.availability_periods.where (end_time - start_time > duration)

预订约会有点棘手。您需要拆分/缩短可用期。例如,假设提供者具有以下可用性:

5月30日 12:00 - 18:00

预约时间为5 月 30 日 14:00 - 16:00

旧的可用性需要删除并替换为两个新的: 5 月 30 日 12:00 - 14:00 5 月 30 日 16:00 - 18:00

但这在模型方法中很容易做到。

于 2015-05-27T18:11:03.453 回答
1

我喜欢 jpriebe 的解决方案,但我会建议对验证稍作改动:(Date.today + 6.months).end_of_day用于范围的最末端。

我提出建议的原因是使系统更加用户友好。如果您使用Time.now,并且用户想要创建一个在下午 4 点结束的 AvailabilityPeriod,但它仍然是凌晨(例如,上午 10:15 左右),那么下午 4 点将超出范围。要创建 AvailabilityPeriod,他们必须记住稍后再回来 - 他们可能会忘记/正在将烤宽面条从烤箱中取出/在此处分散注意力。

诚然,这种情况实际上只有一个可能的时间发生,那就是如果用户正试图在正好6 个月前创建一个 AvailabilityPeriod(例如,5 月 27 日 => 11 月 27 日)。大多数时候,我确信大多数用户不会提前那么远设置可用性周期。尽管如此,使用.end_of_day会将可接受的时间范围延长到适当的一天结束。

于 2015-05-27T21:18:58.027 回答
0

与其任意分割时间段,特别是如果很少有约会可能恰好是一个 30 分钟的间隔,不如创建具有任意开始和停止时间的约会。假设约会不会跨越几天,您可以拥有一个包含多个约会的 Day 模型。您将必须以编程方式处理重叠计算,但这样做不会将您的数据库打死,您只需要加入 Day、Appointment 和 Providers,然后运行计算以找到您的空缺职位。约会可以是 5 分钟或 6 小时。没关系。

于 2015-05-26T17:35:28.940 回答