4 ms·
It's a deceptive example because banks are distributed systems (in that they interoperate with other banks/financial systems, and often have distributed interna
by ludston 3y ago
It's a deceptive example because banks are distributed systems (in that they interoperate with other banks/financial systems, and often have distributed internal database systems across multiple products too). Regular db transactions are insufficient for ensuring consistency across a distributed system, primarily because one of the systems may fail to commit their transaction after the other has succeeded. Even if there is only a single database, protecting data against concurrency issues is still non-trivial even with transactions.
- bastawhiz 3y agoI mean, if your argument is that banks don't use the primitives of a standard RDBMS because their needs aren't serviced by a standard RDBMS, of course it's a bad example because you're talking about how to do something in SQL which isn't done in SQL. But that's not a "bank accounts" problem, that's a "how banks with a non trivial number of systems work" problem. If you were implementing a system for managing bank accounts in a single RDBMS, regular transactions would work.
- ludston 3y agoThe problem is that the industry standard of banking is eventually consistent. Whilst having atomic transactions is necessary, it's not sufficient: Using banks as a teaching metaphor for RDBMS systems is like using animals as a teaching metaphor for polymorphism. From a naive point of view it works, but it does more harm than good because students walk away thinking that they have a solution to a problem that isn't actually sufficient for it.