Not sure if this was mentioned, but MongoDB is strongly consistent while Cassandra is eventually consistent -- at least about a month ago when I looked at it in more detail, though with vector clocks in 0.7, this may be less of an issue.
As for "schema-less" and coupling of database/application, etc.: Using solutions like iBatis/Hibernate allow the application to be abstracted from the database in theory, but in practice, it is very rare that a schema will undergo changes without corresponding changes in the ORM layer. MongoDB's flexibility in regards to schema does allow the application developer more freedom/control but even though MongoDB doesn't enforce a schema in the traditional sense, a logical schema still exists: applications still need to know what Mongo "collections" (analogous to tables) to reference, what keys to use, what fields to retrieves -- just like a typical "enterprise" Java application needs to know what tables, keys, and columns to retrieve. It's just that with MongoDB, if a column/field name is wrong in the application, it is likely to fail silently, rather then throw an exception. In any case, the term "schema-less" is a little deceptive -- one still has to think carefully about how to structure and store one's data in order to leverage the strengths of a particular datastore. Also, I would say that a MongoDB document (think JSON) in a collection called "user" such as: { "_id": "primaryKeyEquivalent", "addresses": [ {"address1"}, {"address2"}, {"address3"} ] } is about as self-documenting as a table "user" and a table "user_addresses" with a one to many FK relationship. On Thu, May 13, 2010 at 7:31 PM, Steve Lihn <stevel...@gmail.com> wrote: > Not sure how to comment on this concept. I guess it infers that the > database and application are no longer loosely coupled, but now strongly > coupled. > I guess too, that java developers will vote yes, while database architect > and DBA will vote no. > > In the "traditional" sense, enterprise data is the soul of a business. Data > has to stand by itself with reasonable information (primary key and foreign > key) to interpret itself. But it appears now with the Mongo approach, the > data store (I won't even call it database) is a byproduct of the mapping > class. Without reading the mapping classes, one can barely understand the > data. How is this going to be accepted by large enterprises? I put a big > question mark on it. > > On top of it, if you follow Hibernate's suggestion of using numeric as > primary keys, your data will be as cryptic as hell. > > > > On Thu, May 13, 2010 at 8:10 PM, philip andrew <philip14...@gmail.com>wrote: > >> MongoDB encourages you to define your schema in your application code by >> using mapping classes. This logically infers that it makes no sense to >> define the schema twice, in the database and in your application code. >> >>