Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Books: an immutable double-entry accounting database service

developer.squareup.com

Post reply on HN
Print view View original

41–50 of 66 posts

Re: Books: an immutable double-entry accounting database service

#41

Post by josephg »

elvinyung wrote: post #40
dragonwriter wrote: post #17

This looks good but some of the background has the air of the kind of artificial problems presented in late night infomercials: > It’s impossible to split a single payment into multiple payouts, since there is a many-to-one relationship of payments to payouts. So your model used a many-to-one relationship when you really wanted a many-to-many? > Since this is just a SQL database, there’s nothing preventing the payout…

(Disclaimer: I work at Square, but not on Books.) >Preventing inconsistencies by enforcing constraints is a key point of an RDBMS. This is literally why people use SQL DBs. This comment is not specific or related to the work at hand, but note that this is only true for a single-machine database or a sharded setup in which you never have to perform transactions across shards. That is, the ACID guarantees are only enfo…

Huh? Am I missing something obvious here? Plenty of databases support ACID guarantees across multiple machines in a cluster. FoundationDB and CockroachDB come to mind, but I’m sure there are others. What you’ve built is cool, but I’m still confused why existing tools aren’t good enough.

From the Cockroach documentation (source: https://www.cockroachlabs.com/docs/stable/transactions.html )

> CockroachDB supports bundling multiple SQL statements into a single all-or-nothing transaction. Each transaction guarantees ACID semantics spanning arbitrary tables and rows, even when data is distributed.

Re: Books: an immutable double-entry accounting database service

#42

Post by nevi-me »

Shouldn't an accounting database service (specifically, the ledger) be immutable and double-entry in any case?

> To address consistency, we picked a well-established, public-domain, battle-tested approach to modeling financials that enables all of our properties ...

I think doing anything other than double-entry leads to reinventing the wheel. When a ledger system is implemented correctly, the main remaining issue becomes scalability.

Re: Books: an immutable double-entry accounting database service

#44

Post by whb07 »

codedokode wrote: post #43

What's good in immutability? If you have found that you have entered too much income and want to lower it, what do you do?

You generate a new item altogether ( I’m talking about immutability). The positives are you’ll have an ability to keep proper records and changes done to your table which will show a different snapshots as it contained different values.

Another plus is that you won’t run into an issue like race conditions where two threads are attempting to change the same thing.

Re: Books: an immutable double-entry accounting database service

#45

Post by nevi-me »

codedokode wrote: post #43

What's good in immutability? If you have found that you have entered too much income and want to lower it, what do you do?

You reverse it with an adjusting entry.

What happens if you've transferred too much from your savings account into your current/cheque account? You make another transaction to adjust the initial one.

Re: Books: an immutable double-entry accounting database service

#46

Post by justinjlynn »

josephg wrote: post #41
elvinyung wrote: post #40

Earlier quoted context omitted.

(Disclaimer: I work at Square, but not on Books.) >Preventing inconsistencies by enforcing constraints is a key point of an RDBMS. This is literally why people use SQL DBs. This comment is not specific or related to the work at hand, but note that this is only true for a single-machine database or a sharded setup in which you never have to perform transactions across shards. That is, the ACID guarantees are only enfo…

Huh? Am I missing something obvious here? Plenty of databases support ACID guarantees across multiple machines in a cluster. FoundationDB and CockroachDB come to mind, but I’m sure there are others. What you’ve built is cool, but I’m still confused why existing tools aren’t good enough. From the Cockroach documentation (source: https://www.cockroachlabs.com/docs/stable/transactions.html ) > CockroachDB supports bundl…

Not everyone has the luxury of using databases like those in high-stakes production.

Re: Books: an immutable double-entry accounting database service

#47

Post by jasim »

Ask the same programmer to write an invoicing & payments system, then coupon creation and track its claims, then something where users can recharge their phone, and their usage is tracked and balance is computed -- and each one of them will be a set of ad-hoc tables and custom code.

But most transactional systems where things move from one entity to another and has the notion of "balance value" is best represented by the double-entry system.

When a customer purchases pre-paid balance, the phone company can record it as a "credit", and every call they make becomes a "debit". This is an immutable log - one of the earliest application of immutable data structures in human history.

In this post authors used positive and negative values to represent debit and credit - we could call it yin and yang for all it mattered. The core principle is just that every transaction has a source and destination and the ledger is an append-only table.

Re: Books: an immutable double-entry accounting database service

#48

Post by elvinyung »

josephg wrote: post #41
elvinyung wrote: post #40

Earlier quoted context omitted.

(Disclaimer: I work at Square, but not on Books.) >Preventing inconsistencies by enforcing constraints is a key point of an RDBMS. This is literally why people use SQL DBs. This comment is not specific or related to the work at hand, but note that this is only true for a single-machine database or a sharded setup in which you never have to perform transactions across shards. That is, the ACID guarantees are only enfo…

Huh? Am I missing something obvious here? Plenty of databases support ACID guarantees across multiple machines in a cluster. FoundationDB and CockroachDB come to mind, but I’m sure there are others. What you’ve built is cool, but I’m still confused why existing tools aren’t good enough. From the Cockroach documentation (source: https://www.cockroachlabs.com/docs/stable/transactions.html ) > CockroachDB supports bundl…

Right -- that's why I said most RDBMS. To get ACID and CAP-consistent (which, as an aside, are not the same thing) cross-shard transactions requires some form of migrating your production system onto such a distributed-capable RDBMS that you describe (of which, Spanner arguably fits the description of).

Re: Books: an immutable double-entry accounting database service

#49

Post by stdbrouw »

I don't see how this schema enforces double-entry accounting. You can specify an entry with a debit, and another with a credit, but they are not linked, their amounts are not necessarily equal and you're not required to simultaneously submit both entries. So this is really a single-entry accounting system that they happen to use to do double-entry accounting. Or am I missing anything?

For those of you reading this who wish to implement a simple system for double-entry accounting, do it like this instead: specify `debit` and `credit` columns with a foreign key to a particular account (what Square calls a "book"), and a field for the `amount`. When, later, you want to calculate the balance of an account, take the sum of all transaction `amount` where `debit = ` and subtract the sum of all transaction `amount` where `credit = `.

Post reply on HN