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.
>>
>>
