Here’s some advice I gave on the Rails-talk list this morning. (Information specific to the question I was answering has been stripped away to make this more of a general-purpose answer.)
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:
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:
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.
Data modelling is actually a lost art. But as a general rule of thumb for beginners, you should avoid duplicitous relationships (also known as circular dependancies).
Note that if one relationship describes a “creditor” (user) and the second one describes a “debtor” (user), 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.
I love creating 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”.