Question

I am working on a small web application that allows users to trade credit to each other. I would like to have your comments on my initial design (efficiency, flexibility, security etc.)

In particular, a typical transaction happens as follow:

User A can offer to do a job in exchange for X credits. Users B and C can accept the offer. A total of X credits will be subtracted from B and C’s accounts. When the job is completed, X credits will be added to A’s account. A can use earned credits to trade with other users.

I am thinking of a database with 3 tables: Job, Transaction and Account. Account table will keep track of credit earned and spent for each user.

Each time a job is done for user B and C by user A:

• Two transactions are recorded in Transaction table: a transfer from B to A, and a transfer from C to A

• Account table will be updated: available credits will be updated in A, B and C’s accounts

• Job table is also updated.

(All these actions will be wrapped in an SQL “transaction”, i.e., all records are updated, or none)

When a transaction is reverted (say, between A and B, but not between A and C), A and B’s Account and Account_History will be updated, transaction between A and B will be set to “revert”.

A sketch in Rails goes as follow:

• class Job

  attributes: :job_id, :total_credit,:created_at, :updated_at

  belongs_to :seller, :class_name => “User” belong_to :buyers,
  :class_name => “User” # one job may be done for multiple users

• class Transaction

  attributes: transaction_id, :buyer_id, :seller_id, :status,
  :credit, :created_at, :updated_at

  belongs_to :seller, :class_name => “User” belongs_to :buyer,
  :class_name => “User # one transaction record per credit swap
  belongs_to :account

• class Account

  attributes: :account_id, :user_id, :available_credit

  belongs_to: user

I am not sure if I should:

1. Create Account_History table to present summary statistics extracted
   from Account table (such as last month transactions, total credit
   earned/spent etc.) to customers, or to store these info in a series
   of cached queries.

   Represent a pending transaction (i.e., when B accepts A’s offer but
   the job is not done yet) and a completed transaction (i.e., when B
   accepts A’s job) in separated records in Transaction table. The
   other option would be just to change status of a transaction from
   pending to completed.

Thanks for your comments.

Answer 1

A more conventional approach would be to use more of a double-entry accounting design.

You can read about this design just about anywhere, but here is a link to a pretty good discussion of what it is and how it works.

The upshot for your design would be that you want a separate table to tie the two pieces of your example transaction into a single unit of work. You want one table that has a single entry per business transaction and another table that one entry for each account involved in that transaction. In the referenced link, these are the JOURNAL and POSTING tables.

In this kind of design, the available credits are not stored in the account, unless you want to do so as a denormalization. Typically the balance is always calculated.

You could decide to have an account balance history table for reporting purposes, but you will need to be sure to handle recalculating this history if your system allows for old transactions to be edited (which it wouldn’t, if it were a conventional accounting system).

If you want to differentiate between transactions that are pending versus those that have been completed, then you can put a status flag on the transaction (in the referenced link, the JOURNAL table). However, there is also a more full-blown accounting convention that would give each user two accounts, one of earned credits and one of unearned credits. In this scheme, using your example, B and C would put some credits into A’s pending credit account. This would create draws on B’s and C’s accounts right away, so that they don’t spend those credits elsewhere. When A completes the job, those credits get moved from A’s pending account to A’s current account. If the job gets cancelled, you’d put in a transaction to transfer back from A’s pending account to B’s and C’s current accounts.

This way may seem a bit more complicated, but it has the distinct advantage of there always being a record of everything that has happened.