I am evaluating MongoDB as a storage solution for our financial/accounting RESTful API. I know about MongoDB’s lack of transactions and decimal data type, however:
I suppose I could overcome the lack of decimals by storing them as integers, and dividing/multiplying them by the precision factor as needed. Consumers are gonna load (GET) and save (PUT/POST) via the API layer, allowing me to take care of the conversion at the API level. Storing integers would allow for computations and atomic updates as needed.
I don’t see MongoDB’s lack of transactions as a show stopper either, at least not in my case: a REST API would not allow for huge, one-call-fits-them-all multi updates. It would be consumer’s resposanbility to implement a rollback logic in case of a failure during a ‘logical’ transaction (a chain of multiple subsequent update calls).
The ‘objects’ stored in the DB would be invoices, inventories, payments… the standard accounting stuff. While the relational data model has proven to be a good solution for storing this kind of data, I don’t see how a schemaless storage would cause trouble. Take the invoice item. I could store each document in a Documents collection, with nested line items. Of course I would still need several collections: Documents, Payments, Contacts and so on, which is why MongoDB’s use of collections looks like a good match to me.
Has anybody done something even remotely similar before? I am still at the design stage so I’d really use some feedback from the MongoDB/REST veterans out there – thanks.
PS: in case you’re wondering, I’d be perfectly fine with a RDBMS solution, but I like to consider alternatives and I see some advantages going the schemaless way. For one, MongoDB outputs JSON/BSON which is what a REST API works with. Second, schemaless means that I can receive a document with a variable number of fields and store it right away, without worrying much about the missing fields (which will be nulls on the DB and will need lots of if IsNULL(fieldname) when building a response to a GET request), etc.
Storing decimals as integers is something that people are doing. If you go through the decimal-support feature request in MongoDB’s jira, you’ll see a couple mention that that’s their workaround:
https://jira.mongodb.org/browse/SERVER-1393
Note that the factor will compound when you do map reduce and stuff which multiplies/divides two or more such numbers.
As for the lack of transactions, it does sound like it won’t be a problem for you today, but what about tomorrow? If your API will always deal with small units of work, then sure. 2-stage commits are always possible too.
I think it’s great to learn new technologies…not going to suggest you don’t. But consider that schemaless really shines when you need to query on those fields. If you don’t, then you could just store them all in a single blobbed-up field/column in either a document or a relational database. (although, every time I’ve seen a project do this, they 3 months down the road they need to start querying/reporting/something on one of those serialized values, and that’s a real pain).