Rails has_one :through association
Logic, OK it might sound a bit weak for this but it would be logical to say that "I have a supplier who has an account with me, I want to see the entire account history of this supplier", so it makes sense for me to be able to access account history from supplier directly.
Efficiency, this for me is the main reason I would use
:through
, simply because this issues a join statement rather than calling supplier, and then account, and then account_history. noticed the number of database calls?using
:through
, 1 call to get the supplier, 1 call to get account_history (rails automatically uses:join
to retrieve through account)using normal association, 1 call to get supplier, 1 call to get account, and 1 call to get account_history
That's what I think =) hope it helps!
Inverse association: consider the classic situation user-membership-group. If a user can be a member in many groups, then a group has many members or users, and a user has many groups. But if the user can only be a member in one group, the group still has many members:
class User has_one :group, :through => :membership
butclass Group has_many :members, :through => memberships
. The intermediate modelmembership
is useful to keep track of the inverse relationship.Expandability: a
has_one :through
relationship can easy be expanded and extended to ahas_many :through
relationship
I'm surprised no one has touched on Association Objects.
A has_many
(or has_one
) :through
relationship facilitates the use of the association object pattern which is when you have two things related to each other, and that relation itself has attributes (ie a date when the association was made or when it expires).
This is considered by some to be a good alternative to the has_and_belongs_to_many
ActiveRecord helper. The reasoning behind this is that it is very likely that you will need to change the nature of the association or add to it, and when you are a couple months into a project, this can be very painful if the relationship were initially set up as a has_and_belongs_to_many
(the second link goes into some detail). If it is set up initially using a has_many :through
relationship, then a couple months into the project it's easy to rename the join model or add attributes to it, making it easier for devs to respond to changing requirements. Plan for change.