Question

Been going back and forth on how to architect this. I’m using rails,and started with Single-Table-Inheritance, then changed my mind, now I’m not sure.

BusinessHours
business_id, day_of_week, start_time, stop_time

StaffHours
staff_id, day_of_week, start_time, stop_time

Obviously a staff member belongs to a business, however the tables for their hours are identical.

Should I store those in one table and add a field like ‘keeper_id’ which stores the id of the staff or business, and a ‘type’ field that store ‘staff_hours’ or
‘business_hours’ to differentiate the two (a staff member and a business may have the same id, so I need to differentiate)

But then I feel like I’m almost back to STI??

Thoughts?

Answer 1

Much depends on your application domain. I don’t think we have enough information here to know exactly what the correct approach is in your situation. For instance, if your application is primarily concerned with managing and reporting on employee and business schedules/hours, and reporting on those schedules, it might make sense to have a single ‘hours’ table, and relate to it polymorphically. This might look like:

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

Here you can still use STI to fork the different Hour functionality if need be. (Note: use the singular when naming your table model, i.e., BusinessHour, not BusinessHours):

class BuisnessHour < Hour
  validates :some_business_hour_rule
end

Etc. The key question with STI is, given what I know about my domain, is it likely I would add many attributes/columns specific to a subclass, such that I would have many null columns in, for instance, a row in the hours table representing a StaffHour object that doesn’t use many of the BusinessHour-specific attributes/columns?

If so, then maybe STI doesn’t make sense for you. But if from what you know about your application’s concerns, the primary difference between subclasses is programmatic and not data-centric, where there are different validations and business rules to operate on mostly identical data, then STI might be the right solution.

I’d sit down with the Product owner (whoever that is) and the other engineers on the team (if there are any) and whiteboard it. If you’re a team of one, whiteboard it anyway and think through what your application will do with these models in the future. If you’re familiar with UML, it can be a very useful tool to help you visualize the data model in a form other than code. If not, this might be a good excuse to learn a bit. Decisions like these can have a huge impact on general code stability down the road.

EDIT:

Another question to ask yourself is, does a Business-specific rule really belong on an Hour object? It could be that it’s more appropriate to have such operations on the Business model itself, and keep Hour simple, unless you truly can imagine a business or staff-specific operation you would call on the Hour model itself. For example this:

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

makes more sense to me from an OOP/SRP standpoint than this:

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

At least, those are the kinds of questions you need to ask to determine the right approach.