Document-oriented databases AKA Semi-structured data are designed for managing, storing and retrieving the document orientation databases. Document data stores are kinds of NoSQL databases. There is no any kind of schema and limitation of fixed table fields and relations of traditional RDBMS databases in Document Store Databases. these databases store documents into a database. You can imagine the document a JSON document (a self-contained data in every document). There is no limitation for fields of these documents, they are completely dynamic and could be modified easily. Document store databases store the data in documents but in a standard encoded formats such as JSON, YAML or XML. These documents are not in a regular form as in relational databases, you can't see any kind of Schema, Primary key, table or relations!
This is a sample of JSON document contained FirstName and Email :
{
FirstName: "Ehsan",
Email: "mails@ehsanghanbari.com"
}
And this is another JSON document for the same person but in another document with a different structure:
{
LastName : "Ghanbari",
Age: "24",
Cell: "+989193782914",
Email: "mails@ehsanghanbari.com",
FirstName:"Ehsan"
}
Both of the documents are my personal information in different formats. As you can see there is no any convention and defined rule for sorting and styling of the data. Where you have to put the same data in the relational database that you have defined before with different kinds of joins and relations. Documents are addressed in the documents via a unique key, this key could be GUID, string, URL or a path. Document databases are a class of storage systems which save the whole object hierarchy to disk and retrieve the same without the use of relational tables. To aid the searching in such databases most Document store databases have a map function which extracts the data needed and saves that as a "view" for later browsing and searching. These databases do away with the notion of transactions and locking mechanism in the traditional sense and offer high data through-put and "eventually consistent" data views. There are lots of document store databases such as BaseX, ClusterPoint, CouchDB, FleetDB, MongoDB, RavenDB and … Document databases generally have very powerful query engines and indexing features that make it easy and fast to execute many different optimized queries.
The benefit of using Document Store Databases:
- Reading from document database makes a better performance because reading related data from different kinds of joins is so slow.
- Documents could be shared between different kinds of nodes. Which allows data to be grouped together more naturally and logically.
- You don’t need to translate the business objects or aggregates(DDDesign) to SQL queries! You have the same document in the database as you have in the model.
- Replication is much easier in a document database because of having the original document (Not inconsistent domain model) in a database.
- You can save any kind of data (Unstructured data) in document databases.
- You don’t need to buy an RDBMS license anymore!
- Changes to the application can be made anytime (what attracts me!)
References:
- http://en.wikipedia.org/wiki/Document-oriented_database
- http://www.browniethoughts.com/2013/02/nosql-databases-key-value-and-document.html
- http://www.codeproject.com/Articles/375413/RaptorDB-the-Document-Store