Database design: accounting transaction table

Question

Storing the transaction entry into a double entry accounting database.

I came up with two solutions option 1 and option 2, I was told most banking p

Answer 1

In a general accounting database design, it is logical and efficient to store your debits and credits in a single fields (i.e. option 2), as this would simplify aggregation,number manipulations and reporting. There should be a datetime field attached to each debit and credit transactions to filter out a particular period. Get the book from Smashwords, titled, accounting database design. It provides some good samples on accounting system design and some interesting sql query for financial reporting.

Answer 2

Option 1 will potentially be a bit more efficient from an insert perspective. But since a lot of accounting transactions are going to affect more than two accounts, the benefit is likely to be substantially less than 2:1.

Option 2 will be clearer for these more complex transactions. That is, an accountant would normally find three rows

• Debit A $100
• Credit B $60
• Credit C $40

more clear than two rows

• Debit A $60 Credit B $60
• Debit A $40 Credit C $40

If you have multiple accounts on both sides, it would also be a bit unclear how to match up the debits and credits to a single account. That is,

• Debit A $100
• Debit B $30
• Credit C $60
• Credit D $70

could be represented as

• Debit A $60 Credit C $60
• Debit A $40 Credit D $40
• Debit B $30 Credit D $30

but there are also other possible ways to construct the data for data model 2.

Additionally, option 2 is going to be more efficient if you're trying to determine the current balance of a particular account by aggregating the transactions.