4 ms·
We're basically talking about bookkeeping systems here, rather than high finance. Use a good relational database. 1. ACID, so you don't have to invent it. 2.
by ibejoeb 2y ago
We're basically talking about bookkeeping systems here, rather than high finance. Use a good relational database.
1. ACID, so you don't have to invent it.
2. Arbitrary precision numeric data types with vetted operations and rounding modes.
3. It does time as well as anyone can
4. Your computations and reporting can be done entirely in SQL.
5. When you get good at SQL or hire someone who is, the reporting is elegant.
6. It's as fast as it needs to be, and a good database architect can make it extremely fast.
7. It has all of the tooling to do disaster prevention and recovery.
I've built so many financial systems for the biggest multinationals in the world, and I have never regretted doing the bulk of the work in the database. Coca-Cola, GE, UPS, AIG, every iteration of the Tycos, basically every pharma with their crazy transfer pricing schemes... Whenever I experienced a performance problem, there have been way to address it that were far easier than what would have been to reinvent all of the hard tech that underlies consistent, accurate financial systems.
- nyrikki 2y agoACID and DTCs will get you in legal trouble with financial systems. That is part of the reason financial systems backed by SQL are so complicated and fragile while old COBOL code keeps going. RDBMS tutorials always use ATMs as an example, but you can't 'roll back' with ATMs, you have to use compensating actions. ACID is useful in many contexts, but actually adds complications to financial transactions. Think of the ledger as being the source of truth, with the DB as simply a materialized view. It has applications with edge caching in web apps too. Events as the source of record can help get rid of cache invalidation challenges compared to cache aside or write back. Two sides errors that don't impact the trial balance is something to search for if you want to know why an ACID DB as the source of truth is problematic in accounting.
- tumetab1 2y ago> 2. Arbitrary precision numeric data types with vetted operations and rounding modes. Be aware that a good rationale for choosing the database but you should enforce a specific precision per table otherwise you can get nasty accounting bugs because you're adding a 3.0095 amount with an 9.99 amount.
- ibejoeb 2y agoYes. The data type itself supports arbitrary precision. I'm not suggesting that you chose the precision arbitrarily.
- deleted 2y ago[deleted]
- throwaway2037 2y agoWhat is the meaning of "high finance"?
- ibejoeb 2y agoSpecialty stuff like high frequency trading, risk models, bespoke instruments, and other non-retail products. Like if you're doing HFT, you're probably rolling your own loops. But the broader point is that this piece is about accounting-related systems that don't typically deal with hard volume, speed, or latency constraints. The term "finance" can mean the corporate "finance & accounting department" but you want to differentiate that from "finance" the industry. The headline does really tell you what actual material is.
- deleted 2y ago[deleted]
- dmoy 2y agoYea this article really should have used "accounting" instead of "finance" (or more specifically, operational accounting). Right, like, if you're a programmer going into a project-for-finance/accounting-team at your large megacorp, and don't know if this article is the right subject area, just ask the finance/accounting person about "year end close" and see if they get a thousand yard stare or not. If yes, this is the right article lol.
- seanhunter 2y ago
- throwaway2037 2y agoThe best systems that I have ever seen have two parts: (a) a read/write relational database (w/SQL) to persist data and (b) a read-only OLAP cube. With enough time, your powerusers will create the most insane reports imaginable using the OLAP cube view.