4 ms·

> Can someone suggest when it is actually useful over a properly tuned relational database? In your own question you kind of hint at it. You need a tuned datab

> Can someone suggest when it is actually useful over a properly tuned relational database? In your own question you kind of hint at it. You need a tuned database. NoSQL lowers the barrier to entry for fast persistent data storage with replication. NoSQL doesn't replace SQL databases, it's looking to optimise a use case where transactions are not required. Personally I use Mongo a bit like a cache, sitting in front of a SQL DB. Things that need to be ACID are handed back and forth. Those that don't are kept in Mongo and I get the best of both worlds.

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 ago
  Document 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.

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 ago
Document 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.