I'm building a web-app where users can keep track of who owes whom money.

I have users and debts. Given a user I want to be able to find out all the debts to other users, and all the loans to other users. Given a debt I want to be able to find out who the debtor and lender are.

The asker of this question ran into a similar situation, but I don't belive our situations similar enough to warrant just using the top answer:


Taken from that question, the three paterns sugested there are

  • well specified associations
  • single table inheritance
  • polymorphic association

What pattern should I use in my situation? One of these three, or is there an even more appropriate one?


I would advice a simpler solution. 2 one-to-many relations, let me explain:

One debt table with 2 user_ids as debitor_id and creditor_id.

like that a user has many loans and many debts, but each debt has only one creditor and one debitor. Both your models and querying are straightforward, and the cases you have mentioned seem to be covered.

NB: while it is possible to for the same 2 users to have multiple loan and debt records, I would recommend against this by validating the uniqueness of the debitor_id, creditor_id combination (if that functionality is not required) in order to simplify querying and having cleaner ORM attributes.

  • why does this solution imply that the same two users can't have multiple loans from one to the other?
    – hhamilton
    Feb 9 '13 at 16:45
  • @hhamilton, you're right. I have edited the answer to better reflect my point.
    – kr1
    Feb 9 '13 at 19:34
  • Thanks for the answer. This is basically what I have implemented right now, but just on a side note I am allowing for more that one debt between users. Say for example, I loaned someone $20 and they borrowed by car. we would need to keep track of both debts. the last part of your answer might work better if it were strictly money based and we didn't want to let the users muck around with the sum of all their debts. I also understand that you did say qualify the suggestion with the phrase "If that functionality is not required". thanks again.
    – hhamilton
    Feb 9 '13 at 20:30
  • +1 for simple answer, people think to over think this sort of thing and complicate their code for no reason. Feb 9 '13 at 22:43

Looks like a straightforward one-many problem

I would approach it as

User 1 - * Debt

User 1 - * Loan

Then all you need are the tables User, Debt and Loan. The relationships are bi-directional.

From your pick list this is "well-specified associations". I don't think inheritance or polymorphism is required in this situation.

  • 1
    but debts dont have many users, the only have one, right? or am I mis-understanding your answer?
    – hhamilton
    Feb 9 '13 at 16:43
  • @hhamilton Rails mostly takes care of this for you, e.g.: class User < ActiveRecord::Base has_many :debts Feb 9 '13 at 20:23
  • but the relations should be both be one to many, right? not many to many? a debt should only have two users involved with it, right? also, isn't you above comment specifying a one to many? if it were many to many wouldn't it be HABTM?
    – hhamilton
    Feb 9 '13 at 20:25
  • Apologies to all - they should have been one to many - my bad.
    – Gary Rowe
    Feb 9 '13 at 21:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.