Diego,
You actually have a very good question here.
I don’t quite see all the foreign keys here, and I only grok 75% of your
specific data model, so I will answer your question generally and give
you some options rather than specifically tell you how to do it.
You probably read that the rails default is to use the class name as the
association name. In the case of multiple associations to the same
classes – possibly through join tables – this is actually a confusing
way to name your associations.
Consider something that is not your data model: An “Article” that has
both an Author (user object) and an Editor (user object)
The standard way to write your association is like so:
class Article < ActiveRecord::Base
belongs_to :user
end
But the problem here is that you actually want two relationships to two
different user objects (one for author and another for editor).
As you have already discovered, you can use a different name for the
association name, as long as you pass class_name as an option to your
association declaration, like so:
class Article < ActiveRecord::Base
belongs_to :author, class_name: “User”
belongs_to :editor, class_name: “User”
end
In the example above, your Article table would have a foreign key for
author and editor (my personal naming convention is to name these
author_user_id and editor_user_id, that way the field conveys both the
relationship itself and the class that it relates to).
The is a really, really good idea because the worst thing in an app is
to have a relationship to a user_id and as the future developer be
scratching your head wondering if the original developer intended that
to be a “editor” or an “author”. I strongly recommend using this style
of naming convention when you will have multiple relationships to the
same classes, as you have in the example below (a user’s relationship to
a billing can be either as a creditor or as a debtor).
Remember, the association name you give is for you (& Rails) to identify
that association elsewhere in your codebase. Although the default is to
use the name of the foreign class, it is by no means required.
As far as you actual question (should you use a direct relationship
between User and Debt or should you use the has_many :through
relationship, using the billings as a join table) – I think I
understand that correctly — there is no one better to answer that than
you. (Without knowing more about your data model I can’t advise).
But I can say that you should avoid duplicitous relationships (also
known as circular dependancies). Note that if one relationship describe
a creditor and the second one describes a debtor, that doesn’t actually
count as duplicitous (for the purpose of my argument). It would be
duplicitous if a foreign key describes the same relationship already
described in another place (like a different foreign key or through a
join table). That’s what you want to avoid.
The confusing part of your data model is that a Debt belongs_to a user
(is that a creditor or debtor relationship? See how using non-default
association names as explained above can be advantageous?)
If the context of the Debt record only has meaning by being related to a
Billing, then it probably doesn’t make sense to also make it have a
user_id (since you can derive that user by examining the relationship to
the Billing object). Again, since you have some tricky stuff going on
with debtors/creditors understand that I may not be understanding your
data model fully.
I would recommend you create an old-fashioned ERD (Entity Relationship
Diagram) on a napkin. Also you might want to learn a little bit about
the ancient art of “3rd Normal Form”.
Hope this help!
Jason