Hot answers tagged document-oriented
There are a lot of differences between the two of them. MongoDB is more like a traditional RDBMS (nobody shoot). CouchDB performs master-master replication. It's pretty well documented in this much ballyhooed blog post.
Try these articles.. http://nosql.mypopescu.com/post/978742866/document-databases-compared-couchdb-mongodb-ravendb http://weblogs.asp.net/britchie/archive/2010/08/17/document-databases-compared-mongodb-couchdb-and-ravendb.aspx
Here's a good article comparing document oriented databases: http://www.mikeperham.com/2009/09/01/comparing-document-oriented-databases/ and here's a good article about designing document oriented databases: http://ayende.com/Blog/archive/2009/03/08/designing-a-document-database.aspx
Some thoughts.... Typically one does not want to store pieces of tightly interrelated information in different systems. The chances of things getting out of sync is significant and now instead of one problem on your hands you have two. One thing you can do with Mongo though is use it to pipeline your data in or data out. My preference is to keep ...
In cases where there is a legitimate option to use a substitute ingredient you can do one of several things, all involving storing the option in the ingredients array. One way could be to add a field to an array element as "allowedSubstitutions": "different liquor" another way would be to turn "ingredient" into an array which lists possible different ...
Generally, Master-Slave is a disaster recovery setup: when master dies, slave becomes master. Manual intervention is needed or you need some redirection layer, You may also have replication lag built in so that master corruption can be stopped before it hits the slave. Clustering is high availability: failover is automatic. You need both HA and DR, not ...
Configure replication as 'Changed and Replicated'.
Are the performance gains from data consistency enough of a reason to develop in NoSQL, rather than relational? I think your question presupposes a certain way of looking at things. Your fundamental tradeoff with NoSQL is a tradeoff between declarative ad hoc reporting and fast and loose inputs. This tradeoff is unacceptable for many (maybe most) ...
It's best not to use the name of a "type" as an id - it is better to use generated id's and have a key called "type" in each document where you have a string value of "Home" etc
Both are currently evolving, so if you chose one today, you may find that you need to switch later. I know of a company that did a thorough review of both, with prototype apps implemented in both, and they made a well-informed choice based on the project requirements. Initially, they had success with their choice, but after about 6 months, some of the ...
Only top voted, non community-wiki answers of a minimum length are eligible