In our previous article, we have discussed about Key-Value Database, which is type of NoSQL database. The document-oriented databases are designed to store, retrieve & manage document-oriented semi structured data. It is normal to compare the document-store with key-value database (we gave some example use cases in caching, image storage, financial sectors including forex trading) as some of the key-value database can “store documents”. In this article, we will try to avoid comparison, rather discuss the basics of a document-store.
Basics of a Document-Oriented Database
NoSQL databases are usually designed to run on less costly commodity servers. A relational database demands powerful, optimized hardware for efficient operation. MySQL can do most of the works we want, but using MySQL for object storage is not cost-effective and fast. Documents can have collections within them (sub-collections), sometimes nested objects. Each of those may consist of detail fields or lists. They are semi-structured data. Document-oriented databases are one of the main types of NoSQL databases. These databases assume that documents encapsulate and encode information in some standard format such as XML, YAML, JSON, BSON and other binary forms, and so on. Documents in a document store are like programming concept against an object :
"Twitter Handler": "@AbhishekCTRL"
You can see from the above example – they are not required to adhere to a standard schema. The Twitter handler is just the handler, instead of an URL. That field is dependent on the need of the application and coding done to render it properly. That is why every object, even of the same class, may look very different.
The core operations which a document-oriented database supports are similar to other databases, which is recognized as CRUD – Creation (insertion), Retrieval (query), Update and Deletion. The documents can be addressed via a unique key, typically a string, or a URI. So, we can say that a document-oriented database is a specialized key-value store. In case of a key-value store, the document content is not transparent. Presently, some of the key-value stores include features to work with metadata. Which blurs the classic difference.