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.
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 ...
Welcome to database hell! NoSQL is often championed as a solution to these types of applications. However, your problem here is clearly that the programmers have no idea what they are doing. Furthermore, it looks like your management is afraid of change, or unwilling to take the hard decisions which you correctly list and which are likely to fix the root ...
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
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 ...
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) ...
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 ...
Apparently, the JDBC driver needs to be loaded before the connection is made by Class.forName("com.orientechnologies.orient.jdbc.OrientJdbcDriver").
Many NoSQL products have sharding built-in. The DBMS itself looks after storing a particular key range on a certain server and keeping redundant copies for high availability. Client connections are routed within the DBMS rather than in the application. Multi-server scale out becomes easy, at the cost of CAP compromises.
Configure replication as 'Changed and Replicated'.
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