4 ms·
I stopped reading when he said consistency is in your hands (with noSQL). Since you have to manage relationships, and doing so requires several round trips to t
by wanderr 16y ago
I stopped reading when he said consistency is in your hands (with noSQL). Since you have to manage relationships, and doing so requires several round trips to the datastore, and generally doesn't involve transactions, what happens when inserts 1 and 2 succeed, but insert 3 fails? What happens if you crash before insert 3?
In high volume applications, these situations will arise and you will end up with inconsistent data. That doesn't prevent noSQL from being useful in some situations, but it's a far cry from putting control over consistency in your hands.
- jchrisa 16y agoCouchDB has full ACID on a single document, so you can avoid these scenarios by writing everything that needs to happen in a transaction into a single document. Modeling your data like this means you are also more robust against partial replications (when using offline mode). It is possible to do banking this way (CouchDB is probably better for banking than relational systems). Here's an example: http://books.couchdb.org/relax/reference/recipes http://books.couchdb.org/relax/reference/recipes
- wanderr 16y agoI'm not too familiar with CouchDB in particular or what exactly a "document" is. Let's say I have a site about books. I need to be able to look up books by author, title, isbn and users who have it in their catalogue. Is there a way in CouchDB to ensure consistency while maintaining those relationships?
- jchrisa 16y agoYes, that's what the incremental map reduce indexes are used for. Each book would be a document, which you could query by any of those attributes. I'd store the fact that each user owns a book as it's own document, and then you can easily get a view of books by user, or of users by book.