Question

I am trying to refactor a half finished project. Original developer has left. In his model design, a separate “period” model is used. So a discount object has a usable period and event can have a period.

The periods table:

  create_table "periods", :force => true do |t|
    t.integer  "owner_id"
    t.string   "owner_type"
    t.datetime "begin"
    t.datetime "end"
    t.datetime "created_at",                               :null => false
    t.datetime "updated_at",                               :null => false
  end

I am starting to feel difficult writing listing queries based on dates. I need to join the period table and sort on that end date field.

What I want to ask is: what are the pros/cons of this approach? I am feeling that moving those back to the belonging models makes more sense.

Answer 1

Making a period table is not necessarily a strange practice: As long as that kind of information is delivered to the project developer’s heir.

And in a case where you would want to know about everything that happened in a given time period, say June, that devision of tables makes perfect sense.

So my point is that I guess it’s about communication and needs. If you don’t need that functionality anymore, I suggest a migration that adds two new columns to all polymorphic tables related to the periods, begins_at and ends_at and then migrates all the data from the periods table into those respect columns.