There's no problem with your has_many :throughs that I can see. But you won't be able to use delegate in that case - because you one Report (eventually) has many Fields, when you delegate you are delegating to a collection, not to a single object.

delegate is simply a shortcut method - for example you could delegate in the other direction:

class Report has_and_belongs_to_many :templates has_many :values class Template has_and_belongs_to_many :reports has_many :sections has_many :columns, through: :sections has_many :fields, through: :columns class Section belongs_to :template has_many :columns class Column belongs_to :section has_many :fields class Field belongs_to :column has_many :values class Value belongs_to :field belongs_to :report delegates :column, to: :field delegates :section, to: :column delegates :template, to: :section

Then a call to @value.template is actually a call to @value.field.column.section.template - but is preferable because, obviously, it's easier to type, but also you are hiding the actual structure of your objects.

So a routine that only ever deals with values can know about the template without knowing about the hierarchy above it, which means you can change it in future with less chance of breaking existing code.

In cases like this I always draw things out - effectively you are doing Database Design, so an Entity Relationship Diagram, although old-fashioned, is exactly the right tool for the job.

I'm not entirely sure what the 3-way relationship would give you - but it depends exactly what goes into a Value - if there are lots of repeated values then Database Normalisation rules state you should extract it into a separate table (or model in Rails terms), which is what the 3-way association gets you. But it depends what a Value is, and sometimes you have to denormalise anyway for performance reasons.