One of the biggest conceptual issues I’ve run into building Roommate App is how to store the account balance between roommates. Each roommate has to be able to both pay bills (create debts) or make payments, and increase or decrease the account balance accordingly. The problem comes when you have to access that account balance as either one of those roommates, and know which roommates needs to pay the amount, and which roommate is owed the amount. It takes a little bit of database knowledge to understand why that’s a problem, but hopefully it will get clearer as I describe the different options. 

In Roommate App 1.0 (Bahoy), I set up two accounts per roommate pair. Each roommate had an “account payable” and an “account receivable”, for another roommate. These two accounts switched names when you looked at them from the perspective of the other roommate. When Roommate A split a bill and created a debt of $100 for Roommate B, it would increase Roommate A’s account receivable by $100. Then the system would check Roommate A’s account payable (a.k.a Roommate B’s account receivable), and if there was a balance of say $50 in that account (meaning Roommate A owed Roommate B $50), it would find the difference between the two accounts and store $50 in Roommate A’s account receivable, and $0 in the account payable. Thereby balancing the two accounts. When accessing that data, the system would check both accounts to find which had the balance, and adjust the sign (positive or negative) depending on which account for which roommate the balance was in. This is fun right?!?

For the zero people still reading this, you may be wondering why you couldn’t just use one account. Well, you can, but here’s the issue. In the accounts table in the database, you would have one account between two roommates, with 3 fields: The account balance, Roommate A, and Roommate B. In Roommate App, there is no naturally dominant roommate, so the first issue you have to solve is which roommate is A and which is B. In this latest rebuild, I actually decided to try this, and defined A as the roommate with the lowest user_id (each roommate has a unique user ID number to help the system keep track of them). So now how it works is when a bill is paid, it compares the roommates’ IDs, finds the right account, and either increases or decreases the balance accordingly. The reason I didn’t go with this method originally is that the ID comparison feels unnatural and dirty to me. One of the biggest issues with this method comes from if I ever want to show a list of all accounts for all other roommates. I can’t just ask the database for “all accounts”, I have to ask for “all accounts where Roommate A = this_roommate or Roommate B = this_roommate”, and then do all the ID comparisons again to figure out the right totals. With the first way I still had to access two accounts, but I already new exactly which account was which.

So now that I’m down to -1 people still reading this (which means even I’m not reading this anymore), I think I’ve found the solution. The first way was originally inspired by business accounting practices, with all the accounts receivable/payable stuff, but I wasn’t smart enough to take that inspiration as far as I needed to. If I had just analyzed the double-entry journal a little more, I could have saved myself all this work (and you the pain of reading this). The new plan is to go back to two accounts. Both accounts will be “accounts receivable” for their respective roommates, but this time those accounts will not double as “accounts payable” for the other roommate. Instead, any time a debt or payment is made, the system will update both accounts. So one account will always be the opposite sign (positive or negative) as the other (except for zero of course). What this allows is for any time I have to get the account balance, I can just look at the current roommate’s account receivable, and I don’t have to do any calculation to find out which roommate is which, or to find out which of two accounts holds the balance. Awesome!

One trick here is having to make those two updates when any transaction is made, but all that requires is flipping the sign and applying it to the other account. Pretty easy actually. The other trick is making sure the two balances stay exactly the opposite amount. If they ever became un-opposite (yeah that’s what I said), that would be really really bad…really. In theory that shouldn’t be hard to do, but fun things like database errors make it a slight possibility that I’ll have to protect against.

Holy crap that was a long post. And the only people that will probably get anything out of it are my future competitors. Maybe I’ll at least get some SEO love out of it because of all the times I said “roommates”. Roommates, Roommates, Roommates. I love Google. Google, Google, Google. :) Polyphasic sleep does weird things to the brain.

I’ll update this once I’ve had a chance to test out my new solution. If you get anything out of this let me know. Or even better, link to it. With roommates in the link text. :D

 

 

 

roommates