Models with similar attributes. Separate tables or STI?

In app i’m working on I have to save Work History and Education History for users

For work history we have: company_name, position, job_description, eplooyed_from employed_to

For education history we have: school_name, degree_level, subject_studied, attended_from, attended_to

As I see it right now, the easies way to do it, is to have separate models/tables and use attribute names as described above, which would reflect real world model little more.

Also in this case STI could be applied, with more general model, like UserHistory with attributes similar to: name, title, description, started_on, ended_on

What would be better approach to do it? Separate models and two tables with model specific attributes or STI with more general attributes and one db table?

Also another way to do it, would be to have one model, and save name, title, description in hstore columns in hash + started_on, ended_on columns for data

P.S. i think i would need to search for university name and speciality in future

Hi Mike, I’m going through the same issues (my post about this issue is just a few below yours on the board as of this writing!), so I’m no expert, but if I was tackling your case, it seems like the Work History and Education history are very different things, so I’m not sure I’d try and make them inherit from a common class or share a table in the DB.

It seems like you would have a user model and the user would have_many work_histories and have_many education_histories, each history is it’s own table.

From what I understand, STI is for when the two objects would share identical columns in the DB, just behave differently. Also, you would use class inheritance if there was a strong common abstract tie between the histories, but would have different columns. In this case, I don’t see them having enough commonality to relate either. it seems like their only link is the user, and the user model is already in your application, so a history abstraction would just basically be copying the user model, and that would be unnecessary duplication.

Hope this helps!