http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Karl, For the most part, MongoDB is a drastically different beast than CouchDB or RavenDB. You are correct, by the way, in that MongoDB's idea of how to deal with documents isn't really a key based approach. I would say that you _id is much more than an implementation details, this is how you address the document, and MongoDB has a lot of support to make this as fast as possible. But yes, while you _can_ do something like this: db.people.findOne( { _id: ObjectId( "47cc67093475061e3d95369d" ) } ) That isn't really how I think about a key store. http://ayende.com/4459/that-no-sql-thing-document-databases#comment10http://ayende.com/4459/that-no-sql-thing-document-databases#comment10Tue, 20 Apr 2010 20:35:37 GMTI can't agree that a document db is, at its core, a key/value store. A key value store is a document db, but not all document dbs are key value stores. The definition of a key value store is that the data can only be accessed by key - this is fundamental to what they are. MongoDB, CouchDB and presumably RavenDB allow, as you state, more complex querying. Once you allow for secondary indexes, you are very far away from key/value. My experience is more with MongoDB, so I can speak about it best. Sure it requires an _id, but that's an internal implementation detail...you can skip it and it'll generate one for you (I wouldn't be surprised if SQL server did the same thing when no PK was present). Also, the structure of a MongoDB document isn't keyed at all, the _id is part of the document, not the key of the document. http://ayende.com/4459/that-no-sql-thing-document-databases#comment9http://ayende.com/4459/that-no-sql-thing-document-databases#comment9Tue, 20 Apr 2010 18:59:12 GMTParag, Yes, I think it would be ideally suited for that. It is a much more natural model for those sort of things than a RDBMS. http://ayende.com/4459/that-no-sql-thing-document-databases#comment8http://ayende.com/4459/that-no-sql-thing-document-databases#comment8Tue, 13 Apr 2010 04:04:52 GMT@Parag: To my understanding, the initial meaning for 'NoSQL' was actually intended to be 'NOSQL' (standing for N.ot O.nly SQL) rather than the more often-used colloquialism 'NoSQL' taken to me 'No' SQL at all. This original meaning would be closer to the spirit of what you suggest ('PlusSQL') than the more common (mis)interpretation as being 'against' SQL in its entirety. Sadly, I cannot seem to find an authoritative reference to corroborate my understanding in any 'official' sense, but I do believe this was its initial intent. -Steve B. http://ayende.com/4459/that-no-sql-thing-document-databases#comment7http://ayende.com/4459/that-no-sql-thing-document-databases#comment7Mon, 12 Apr 2010 14:36:49 GMTDo you think this can be excellent source to store Temporal data for eg, an Invoice document etc ? The more I search, the more I realize it's not replacement to RDBMS but can be excellent addon to store Temporal and denornmized data which most systems seems to be having(think invoice, think payment receipt etc). I think NoSQL should be renamed to PlusSQL or something similar :) http://ayende.com/4459/that-no-sql-thing-document-databases#comment6http://ayende.com/4459/that-no-sql-thing-document-databases#comment6Mon, 12 Apr 2010 13:18:04 GMTCan I ask few questions? What is the underlying storage of Raven DB? Esent? If so, what about its performance? Does Raven support distributed transactions/System.Transactions API? I'd be happy to use it if it supported DTC, I'm thinking about transactional message queue & document operations, which is quite common pattern. Or maybe you have an idea how to implement transactional document & MQ operations without DTC? http://ayende.com/4459/that-no-sql-thing-document-databases#comment5http://ayende.com/4459/that-no-sql-thing-document-databases#comment5Mon, 12 Apr 2010 06:03:10 GMTJason, A DocDBs isn't really about replacing RDBMS, those still have an important role to play. I'll talk about usecases for DocDbs in a future post http://ayende.com/4459/that-no-sql-thing-document-databases#comment4http://ayende.com/4459/that-no-sql-thing-document-databases#comment4Sun, 11 Apr 2010 22:04:37 GMTwith the RESTful JSON access it sounds like Raven is a good candidate for view model persistence. Since raven takes care of the Lucene indexing through linq views it's that much easier to introduce searching into an application. (searching as I have heard Udi describe it). I'm still on the fence if a document DB should replace a RDBMS, but that could simply be my own resistance to change. I know everyone says "what about reporting". I think that is where an RDBMS comes into play. store the domain and/or view data in the document DB and export data to an RDBMS for reporting/mining. http://ayende.com/4459/that-no-sql-thing-document-databases#comment3http://ayende.com/4459/that-no-sql-thing-document-databases#comment3Sun, 11 Apr 2010 21:24:10 GMTEric, I read through the code base of CouchDB, went over all the documentation available for CouchDB, etc. Nothing spectacular, I am afraid. http://ayende.com/4459/that-no-sql-thing-document-databases#comment2http://ayende.com/4459/that-no-sql-thing-document-databases#comment2Sun, 11 Apr 2010 20:59:38 GMTFor those of us that are still trying to wrap our heads around document databases, their uses as well as the paradigm in general, would you recommend some reading material? For instance, I understand the relatively easy concept of serializing and deserializing POCO's to and from JSON (or some other format) for storage and retrieval. There's a ton of material about the easy parts of the paradigm. But I haven't been able to find a good reference for the harder concepts such as differences between querying data in a RDMS and document database. Or for that matter the proper way data should be queried in document databases. What material did you use to learn document databases? http://ayende.com/4459/that-no-sql-thing-document-databases#comment1http://ayende.com/4459/that-no-sql-thing-document-databases#comment1Sun, 11 Apr 2010 19:08:15 GMT