But NoSQL is pretty much based on the idea that you store data from your application in a way which is close to the internal data structures, is it not? Since you aren't dealing with the ability to do on-the-fly, ad hoc transformation (the RDBMS and ORDBMS model) then you are limited more or less to a transactional state persistence layer, which is what the OODBMs's were intended to be. It doesn't really solve any of the problems that beset the OODBMS and other app-specific storage layer. It does solve all the problems that OODBMSs solved and a few more.
I can't see why one wouldn't see NoSQL as essentially a continued outgrowth of the OODBMS movement to be honest.
In essence for complex data it seems to me you have two choices:
1) Insist on rigidly mathematically defined input, allow ad-hoc transformation on output. Input is rigid, output is flexible, or
2) Be flexible with input, and allow some transformation both in input and calling on output. Input is flexible but output is pretty rigid.
the first is an RDBMS, and possibly the array-native databases in the NoSQL world, while the second is the OODBMS, and the vast majority of NoSQL products.
I think this fundamentally gets us to Stonebraker's 4-fold division, where on the left hand side you have simple data:
With query = RDBMS
Without Query = Filesystem
On the right hand side you have complex data (nested structures and the like):
With query: ORDBMS
Without Query: OODBMS
I don't think there is any question that the key problems of operating without declarative queries that can transform data reliably on data output (and this requires fixed schemas for data input) are the same whether you are dealing with OODBMS's or NoSQL db's.
> But NoSQL is pretty much based on the idea that you store data from your application in a way which is close to the internal data structures, is it not?
IMO, it's not. Try BigTable on Google App Engine, or HBase for some examples. IMO, these are often more difficult to relate to a programming model than a traditional RDBMS due to their inherent limitations. Of course, their structure is one of Columns/Rows as well.
One of the problems with describing NoSQL as a movement is that there are a broad range of solutions to a broad range of problems that are being covered by the same terminology.
On the other hand, I suppose there are quite a few NoSQL solutions that do not require structured input data and therefore may appear attractive to people who don't want to maintain rigid structures for data input. That's always seemed like more hype than reality to me, though. I've had pretty good experiences with evolving schemas within PostgreSQL and other SQL systems, and the challenges faced (data migration, dealing with old data in the model, etc) were essentially the same that I would have faced with something like a MongoDB system. I don't really see the advantage of NoSQL there at all. I can also see how they could be viewed as essentially OODB 2.0, and they may very well fall by the wayside for a lot of the same reasons.
I can't see why one wouldn't see NoSQL as essentially a continued outgrowth of the OODBMS movement to be honest.
In essence for complex data it seems to me you have two choices:
1) Insist on rigidly mathematically defined input, allow ad-hoc transformation on output. Input is rigid, output is flexible, or
2) Be flexible with input, and allow some transformation both in input and calling on output. Input is flexible but output is pretty rigid.
the first is an RDBMS, and possibly the array-native databases in the NoSQL world, while the second is the OODBMS, and the vast majority of NoSQL products.
I think this fundamentally gets us to Stonebraker's 4-fold division, where on the left hand side you have simple data:
With query = RDBMS Without Query = Filesystem
On the right hand side you have complex data (nested structures and the like):
With query: ORDBMS Without Query: OODBMS
I don't think there is any question that the key problems of operating without declarative queries that can transform data reliably on data output (and this requires fixed schemas for data input) are the same whether you are dealing with OODBMS's or NoSQL db's.