ruby-on-rails - 营业时间与员工时间关系的推荐数据库设计

Question

一直在反复讨论如何构建它。我正在使用 Rails，并从单表继承开始，然后改变了主意，现在我不确定。

营业时间 business_id, day_of_week, start_time, stop_time

工作时间 staff_id, day_of_week, start_time, stop_time

显然，一名员工属于一家企业，但他们的工作时间表是相同的。

我是否应该将它们存储在一个表中并添加一个像“keeper_id”这样的字段来存储员工或企业的 ID，以及一个“type”字段来存储“staff_hours”或 'business_hours' 区分两者(员工和商家可能有相同的id，所以我需要区分)

但后来我觉得我快要回到 STI 了？？

想法？

Answer 1

很大程度上取决于您的应用领域。我认为我们这里没有足够的信息来准确了解您所处情况的正确方法。例如，如果您的应用程序主要关注管理和报告员工和业务时间表/时间，以及报告这些时间表，那么拥有一个“小时”表并以多态方式与其关联可能是有意义的。这可能看起来像:

class Business < ActiveRecord::Base
  has_many :hours, :as => :scheduleable
end

class Staff < ActiveRecord::Base
  has_many :hours, :as => :scheduleable
end

class Hour < ActiveRecord::Base
  belongs_to :scheduleable, :polymorphic => true
end

如果需要，您仍然可以在这里使用 STI 来 fork 不同的 Hour 功能。 (注意:在命名您的 table 模型时使用单数，即 BusinessHour，而不是 BusinessHours):

class BuisnessHour < Hour
  validates :some_business_hour_rule
end

等等。 STI 的关键问题是，鉴于我对我的域的了解，我是否可能会添加许多特定于子类的属性/列，这样我就会有许多空列，例如，小时表中的一行代表不使用许多特定于 BusinessHour 的属性/列的 StaffHour 对象？

如果是这样，那么 STI 可能对您没有意义。但是，如果根据您对应用程序关注点的了解，子类之间的主要区别是程序化的而不是以数据为中心的，其中有不同的验证和业务规则来对大部分相同的数据进行操作，那么 STI 可能是正确的解决方案。

我会与产品负责人(无论是谁)和团队中的其他工程师(如果有的话)坐下来，并将其写在白板上。如果你们是一个人的团队，无论如何都要将它写在白板上，并仔细考虑您的应用程序将来会用这些模型做什么。如果您熟悉 UML，它可能是一个非常有用的工具，可以帮助您以代码以外的形式可视化数据模型。如果没有，这可能是学习一点的好借口。像这样的决定会对以后的一般代码稳定性产生巨大影响。

编辑:

要问自己的另一个问题是，特定于业务的规则真的属于 Hour 对象吗？在业务模型本身上进行此类操作并保持 Hour 简单可能更合适，除非您真的可以想象您会调用 Hour 模型本身的业务或特定于员工的操作。例如这个:

class Business < ActiveRecord::Base
  def calculate_monthly_cost
    # operates on hours 
  end
end

从 OOP/SRP 的角度来看，这对我来说比这更有意义:

class BusinessHour < Hour
  def calculate_business_cost
    # operates on business or uses business-specific rule 
  end
end

至少，这些是您需要提出的问题以确定正确的方法。