Question

I am new to Ruby on Rails (which may soon be obvious) and I’m trying to figure out a model for the following data scenario. I have read several posts and searched Google at length, but I’m still confused.

I have 5 different tables with identical columns, except the value column has a different data type. They data is in 5 separate tables for a variety of good reasons, but think of it as data sharded across multiple tables.

logbook_strings (user_id, entry_id, field_id, value) 
logbook_booleans (user_id, entry_id, field_id, value)  
logbook_integers (user_id, entry_id, field_id, value)  
logbook_decimals (user_id, entry_id, field_id, value)  
logbook_datetimes (user_id, entry_id, field_id, value)  

So here’s what the data would look like:

------------------------------------------------
| user_id | entry_id | field_id | value        |
------------------------------------------------
| 1       | alpha1   | date     | 2012-11-14   |
| 1       | alpha1   | duration | 1.2          |
| 1       | alpha1   | remarks  | Nice job.    |
------------------------------------------------
| 1       | alpha2   | date     | 2012-11-13   |
| 1       | alpha2   | duration | 2.7          |
| 1       | alpha2   | remarks  | Bad job.     |
------------------------------------------------

Entry alpha1:
2012-11-14, 1.2, Nice Job.

Entry alpha2:
2012-11-13, 2.7, Bad job.

etc.

The reason I do this is so that I can have an infinitely flexible database. I can add a new field_id at any time to add a new field/feature to my app instead of doing a schema update to add yet another column to a wide logbook table.

So what I’m wondering, is there a way I can have a single ActiveRecord model in which I can reference all 5 of these tables?

Answer 1

After spending a few minutes trying to shoehorn this into a single ActiveRecord class, I don’t think it’s a great idea to use ActiveRecord for something like this. I see a few options:

• Roll your own model. The extreme downside to this approach is that you lose out on all of ActiveRecord’s many nice features. But if your data is relatively simple (not a lot of associations, etc.) then this might be a viable option.
• Restructure your data. If this schema/data is either pre-existing or has to match a mobile app’s schema for some reason or another, this might not be an option. But if you’re starting fresh, Rails’ migrations make adding/removing columns on a whim extremely easy and very safe so I might consider using a more traditional approach. While this may not seem ideal, it’s something to seriously consider in order to gain the many benefits of ActiveRecord.

If you must keep your schema, creating a separate model for each logbook table could be your best option.

# Migrations
create_table :logbook do |t|
  # Default fields, nothing special
end

create_table :logbook_integers do |t|
  t.integer :logbook_id  # You'd probably want to index this as well
  t.string :name
  t.integer :value
end

create_table :logbook_strings do |t|
  t.integer :logbook_id   # You'd probably want to index this as well
  t.string :name
  t.string :value
end

# etc...

# Models
class Logbook < ActiveRecord::Base
  has_many :logbook_integers
  has_many :logbook_strings
  # etc...

  def remarks
    self.logbook_strings.find_by_name("remarks").value
  end

  def remarks= newValue
    remark = self.logbook_strings.find_or_create_by_name("remarks")
    remark.value = newValue
    remark.save
  end

  # etc...
end

class LogbookInteger < ActiveRecord::Base
  belongs_to :logbook
end

class LogbookString < ActiveRecord::Base
  belongs_to :logbook
end

# etc...

# Usage

logbook = Logbook.new
logbook.remarks = "Hi"
logbook.duration = 2

logbook.remarks         # => Hi
logbook.duration        # => 2

If you can change your schema a bit, here’s an option:

You can use the serialize class method described here (cmd+f for ‘serialize’) to store your entries so instead of having many models, you just have two: Logbook and LogbookField. It might look something like this:

# Migration for logbook_fields
create_table :logbook_fields do |t|
  t.string :name
  t.string :value
end

# Models
class Logbook
  has_many :logbook_fields

  def self.build_with_default_fields
    self.logbook_fields.create name: "date"
    self.logbook_fields.create name: "duration"
    # etc...
  end

  # You could probably do some cool Ruby metaprogramming to create all these
  # accessors/setters for you, btw.
  def date
    self.logbook_fields.find_by_name "date"
  end

  def date= newValue
    field = self.logbook_fields.find_by_name "date"
    field.value = newValue
    field.save
  end


  def duration
    self.logbook_fields.find_by_name "duration"
  end

  def duration= newValue
    field = self.logbook_fields.find_by_name "duration"
    field.value = newValue
    field.save
  end

  # etc...

end

class LogbookField
  serialize :value

  belongs_to :logbook
end

# Usage

logbook = Logbook.build_with_default_fields
logbook.date = DateTime.now
logbook.duration = 2.7

Something to that effect. That way you retain most all the ActiveRecord niceties while still maintaining some of the “infinite-ness” of your schema design. However, adding/removing columns on a single table with migrations would probably prove easier than this even. Again, it depends on whether you can be flexible in your schema or not. Hope this helps.