NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



Ongoing comparison of OODBs and NoSQL

Last week I tried to briefly present the main differences between OODB and NoSQL. Roberto Zicari, over ☞ ODBMS Industry Watch, is looking into this topic in more detail and in his last post, he invited a few people to answer this question.

I am including below the ones I’ve found most interesting, but I’d encourage you to check the original article and let me know which ones are your favorites.

Peter Norvig (Director of Research at Google Inc.): “You should probably use what works for you and not worry about what people call it.”

Miguel-Angel Sicilia (University of Alcalá): “[…] I do not see NoSQL and ODBMS as overlapping, but as complementary solutions for non-traditional data management problems.”

Jan Lehnardt (CouchDB): ” For me, NoSQL is about choice. OODBs give users a choice. By that definition though, Excel is a NoSQL storage solution and I wouldn’t support that idea :) I think, as usual, common sense needs to be applied. Prescriptive categorisation rarely helps but those who are in the business of categorising.”

Dwight Merriman, (CEO of 10gen): “A comparison of document-oriented and object-oriented databases is fascinating as they are philosophically more different than one might at first expect.”

Erik Falsken (db4o): “[…] The complexity of object relationships is their shared drawback. Being unable to handle things like inheritance and polymorphism is what stops them from becoming object databases. You can think of db4o as a “document-oriented database” which has been extended to support object-oriented principles.”

Tobias Downer (MckoiDB): “[…] I wouldn’t count on the word being in our lexicon for very long though or any products seriously branding themselves using this label, because these systems are likely to eventually come back around and support SQL like query languages in the future.”

I guess only time will tell which ones got this right and which didn’t.