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 ...
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
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
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) ...
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 ...
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 ...
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
Configure replication as 'Changed and Replicated'.
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.
Apparently, the JDBC driver needs to be loaded before the connection is made by Class.forName("com.orientechnologies.orient.jdbc.OrientJdbcDriver").
As an alternative, if you have Solr already set up, you can have it index your document and return it to you in multiple formats (JSON, XML, even Python dictionaries). Solr offers a way to search through your information really fast as well as allowing you to do faceted queries as well. While creating your own denormalized structure in a RDBMS would ...
Only top voted, non community-wiki answers of a minimum length are eligible