3 ms·
> NoSQL doesn't replace SQL databases, it's looking to optimise a use case where transactions are not required. I'd be curious to know in what contexts anyone
by ddebernardy 12y ago
> NoSQL doesn't replace SQL databases, it's looking to optimise a use case where transactions are not required.
I'd be curious to know in what contexts anyone would not want transactions.
I readily see the case for memcached or equivalent when it comes to caching -- it is very valid, and indeed useful, when slightly outdated data is perfectly acceptable. I can even picture how you might be using MongoDB to do the same, even if you admittedly have me wondering how you're invalidating the mess.
For a persistent data store, however, I'm honestly at a loss. In my own experience, transactions are needed as soon as there's a remote possibility that a concurrent write may occur. Even embedded systems need them, when you're threading statements concurrently for performance reasons, or when you're subsequently merging local data with another node. (See CoreData/iCloud bugs for what occurs when you ignore ACID in the latter case.)
- jbergens 12y agoDocument databases normally has atomic updates of a document. This may contain many parts and would require transactions in a relational db. Meaning you kind of get some transactions automatically. Other things are not possible to make transactions around and then you must try to create the app to handle the problems. And some document databases can actually use transactions, like FoundationDb.