ravendb: All content tagged as ravendb in NoSQL databases and polyglot persistence
This will be a project written for the sole purpose of demonstrating how to use RavenDB and how to write testable code against RavenDB – this will be demonstrated by utilising some basic TDD principles in order to drive the code surrounding the RavenDB infrastructure and usage.
Unfortunately there’s no easy way to navigate these posts, so here are links to them in order:
- ☞ part 1: introduction
- ☞ part 2: setup
- ☞ part 3: application lifecycle
- ☞ part 4: tracking documents
- ☞ part 5: structure
- ☞ part 6: entities, repositories, and commands
- ☞ part 7: user registration
Additionally you have a ☞ debate about RavenDB documents and entities.
But before using this as a reference material there are a couple of corrections needed:
They have some special characteristics that make them kick some serious SQL.
- Objects can be stored as documents: The relational database impedance mismatch is gone. Just serialize the object model to a document and go.
- Documents can be complex: Entire object models can be read & written at once. No need to perform a series of insert statements or create complex stored procs.
- Documents are independent: Improves performance and decreases concurrency side effects
- Open Formats: Documents are described using JSON or XML or derivatives. Clean & self-describing.
- Schema free: Strict schemas are great, until they change. Schema free gives flexibility for evolving system without forcing the existing data to be restructured.
- Built-in Versioning: Most document databases support versioning of documents with the flip of a switch.
- Judging by the growing number of document database mapping tools, I’m not sure impedance mismatch is really gone (related to 1st point above)
- Using embedded format is not always the best solution for mapping relationships and other more complex data structures. (related to 2nd and 3rd points above)
- Versioning is an extra-feature that is not fundamental to document databases. MongoDB and CouchDB do not support it by default, but there are different solutions available
Related to the matrix comparison:
- Versioning is not supported by either MongoDB and CouchDB. MVCC should not be confused for document versioning
- Sharding: CouchDB doesn’t support sharding out of teh box. There are different solutions for scaling CouchDB, using Cloudant Dynamo-like scaling solution for CouchDB, or even running CouchDB with a Riak backend
- Replication: both MongoDB and CouchDB support master/master and master/slave
- Security: check firstly the NoSQL databases and security post and decide for yourself and the “basic” level is enough for your app
Original title and link for this post: Document Databases Compared: CouchDB, MongoDB, RavenDB (published on the NoSQL blog: myNoSQL)