4 ms·
Mongo shouldn't be used for financial applications, it doesn't have ACID support.
by SomeoneWeird 13y ago
Mongo shouldn't be used for financial applications, it doesn't have ACID support.
- mbesto 13y agoWhy, today, people refuse to use trusted SQL RDBMS's still boggles my mind...
- gnu8 13y agoSQL isn't buzzword compliant. It's ironic really. MongoDB is the new Oracle, while Oracle would actually be a reasonable solution here.
- tzs 13y agoI think the problem is more with the architects of the applications than with Mongo. You can safely use a non-ACID database for financial applications. You just have to take care of the parts of ACID you need yourself. It's tricky to get that right, though, so most developers would be much better off picking a database that does it for them.
- jasondc 13y agoI've worked on a few large scale financial databases and none of the ones I've worked on use transactions (using Oracle). Most of them are insert only with bi-temporal data: http://en.wikipedia.org/wiki/Bitemporal_Modeling http://en.wikipedia.org/wiki/Bitemporal_Modeling
- lclarkmichalek 13y agoDo you have any more info on that technique? The wikipedia article is a little scarce.
- buro9 13y agoA simple entry into the field is to imagine that instead of storing a row in which you have a single balance, you would instead have an append-only table in which you store all transactions including their timestamp and auditing info. The balance would then be calculated as the sum of transactions, and you could modify the query to view a balance in the past by only including transactions before a certain point in time. A reversal or correction would be an append action, not a modification to existing data. Thus giving you an accurate history of the data. This is a simple entry point, as bitemporal modelling usually affects the entire datastore and also has to handle potentially massive data and so requires ideas of how to archive old data, and provide performant ways of knowing the current state. There are lots of tricks here, and the sum of those tricks is how bitemporal modelling is achieved.
- jes5199 13y agoI've seen the before-and-after at a company that didn't use this sort of modelling and then added it. It was like night and day - suddenly we stopped making embarrassing errors with people's money. Even without really optimizing it for speed, and just using MySQL, and without changing any of the other data model, it works.
- jasondc 13y agoInteresting, could you describe how the errors occurred?
- jes5199 13y agonot in detail, but imagine: you have code that walks a complex object graph every day to figure out how much money to move. The business rules interact in complicated ways. Do you trust that you'll always get the same value out of that system? Versus "select sum(value)" as a single query...
- jasondc 13y agoSure, this post helps describe the design: http://www.codeproject.com/Articles/17637/Bitemporal-Database-Table-Design-The-Basics http://www.codeproject.com/Articles/17637/Bitemporal-Databas...