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.

In the last couple of hours I read two interesting comparisons of object-oriented databases and NoSQL stores.

The first one, published on the ☞ ODBMS Industry Watch blog, comes from Anat Gafni, VP of Engineering at db4objects which suggests using the following criteria:

By each dimension of the purpose of OODBS:

1. persistent (could be accomplished by other methods like: replicating to other machines, using non-volatile caches, etc.)
2. Being queriable
3. Scalable (beyond what can be in cache, but could be distributed instead)
4. Objects vs.Relations

Arguable properties:

1. can express and query based on complex relationships among data items
2. can be shared among multiple “clients”

Many of these other database are similar to oodbs in item 1, 3 and 4. I am not sure they have capabilities in 3, 5 and 6 above.

A couple of criteria are either pretty vague or too generic (f.e. 2, 5, 6), but I’d say the comparison is pretty fair.

The other short comparison was given by Mike Dirolf in a MongoDB presentation:

while they use fairly similar concepts, the main difference is that in OODB you are saving instances, in document databases you are saving data.

Anything else we should be adding to these?