3 ms·
That isn't necessarily "how SQL works". Sure, you might design your schema like that. But many accounting systems don't necessarily store a "balance" except per
by nbevans 4y ago
That isn't necessarily "how SQL works". Sure, you might design your schema like that. But many accounting systems don't necessarily store a "balance" except perhaps as a performance optimisation. They derive the balance from the history of transactions that have occurred on an account. And a transaction is, essentially, a + or - value.
Indeed it can be argued that CRDTs are a natural fit for SQL because it is essentially a derivative of set theory
- bawolff 4y agoIf you are essentially going to just have inserts that are not dependent on any reads, why are you bothering with fancy algorithms like CDRT? That is the trivial case.
- fauigerzigerk 4y agoI think the question is whether this particular CRDT has any notion of transactions to make sure the database is left in a consistent state after a merge. As I understand it, the only guarantee we get from all CRDTs is that all copies end up in the same state irrespective of merge order. And then there are some trivial examples, like counters, where this state is also logically consistent. But that is not guaranteed in general. So what about the classical example of transferring an amount from account A to account B if account A has sufficient funds? I think for a CRDT to support such cases (for arbitrary schemas) it would have to have some notion of atomicity and some way to specify preconditions.