Friendly Intro to Document Oriented Databases
Tags: database, webdev, programming
Published: 2021-05-24 20:06:27

Choosing a database for your application is a critical and important part of software development cycle. There is no shortage of database options that you can chose and this just adds more complexity to the whole process. Personally i use Document oriented databases most of the time and this doesn't mean that Document oriented databases are the best solution for your database all the time, they do come with some albeit a few drawbacks but i think the benefits outweighs the drawbacks. One type of database you could use alternatively is Relational Databases, I recently made an article about Relational Databases and if you missed that, you can go over it [here](https://dev.to/kalashin1/a-note-on-relational-databases-42hj).  

## What are Document Oriented Databases

Document oriented database are a type database that allows you to organize and store your data into documents. The documents represent an individual record in our data. A document is just an object with key-value pairs. If you are familiar with JavaScript a document is similar to an object literal. Or a dictionary in python. Each document must belong to a collection, which in itself is just a reference to one or more documents that looks alike. You can think of it like this; a collection is a folder that holds multiple documents while documents are just files inside the collection that contains the actual data. Conceptually a collection is similar to a MySQL table, while documents are similar to the rows on a table. The keys on each document represents the columns, each document can have one or more keys. The keys holds a value which is usually of any type e.g(strings, numbers, dates, arrays, objects) e.t.c. The main take away here is that instead of defining how the data should look like on the collection like we do in a relational database with a table, each document actually specifies what it looks like that is why we define keys on the document. However this doesnt mean that we can be haphazard and do whatever we like, we have to ensure that each collection is consistent with the type of document stored inside to prevent errors when we are updating or retrieving data from the database.

visit [Netcreed](https://blog.thenetcreed.com) to read more articles like this.

A typical example of a document oriented database collection
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/anjhtsfktla1yfc2x37c.png)

A typical example of a document oriented database document
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bdhp18l6u75euin0slz5.png)

## Benefits Of Document Oriented Databases

* Document oriented database are developer friendly, they allow you to organize, store and retrieve your data in a format that is compatible with how it is consumed, basically what you get in the frontend is exactly how it looks in the backend albeit with some few changes so you don't need to write any data transformation logic keeping your database in sync with the frontend.
* Most Document oriented database service providers allow for flexible payment method rather than a fixed system you get with SQL database and in fact you end up only paying for as much as you use, i.e you are billed as per a set number of document reads and writes for a given period saving you some extra bucks. The best part is that most of the service providers have a free tier so you can even build some simple apps that utilizes this cool feature without worrying too much about paying any money initially.
* Document Oriented database service providers actually give you this database as a service, every other aspect of the database is automatically handled for you, you don't need worry about  data storage locations, electricity, scaling up your database, equipment management and all of that jazz. You can focus on what developers like to focus on and leave your worries not to God in this case but your document oriented database service providers. 
* These type of database comes with a query language that is quite easy to learn and use, and allows you to do much more with just fewer lines of code. Although i have enjoyed working with SQL, the language is declarative and has a lot of keywords you need to remember, we already have many frameworks and languages to worry about! Most document oriented database have a query language that is expressive with few keywords and is actually implemented in a programming language you are already familiar with so you need not worry about having to learn a new language from scratch again.
* You don't have to worry about normalizing your data and figuring out how one thing is related to another thing, you do not have to separate information that deserves to be grouped together, you can keep everything you need to be together together. You only need to read a single document to get all the information you need, which means faster load response time. Personally i like keeping things together rather than in different places except of course there is no way around it.

## Drawbacks of Document Oriented Database

I wont say that document oriented databases comes with only benefits and no pain in the neck, there is some drawbacks to using document oriented database and the more common ones include:

* A schema is not automatically created for you when you create a collection or add a document to a collection thus if you don't implement one you can be having documents with key-value pairs that are not on other documents causing havoc when you want to retrieve or update data.
* Data modeling is quite complicated with document oriented database because it is entirely up to you to choose how you want to model your data. If you are a beginner programmer this can be a little too much for you and even if you are experienced, you have to spend some time on the table doing some structuring.
* Performing joins is actually quite difficult in document oriented database because from the ground up they are not designed to handle relational data so you would rely on your data modeling technique to work a way around this.

## Document Oriented Databases

* [**Firesore**](https://firebase.google.com/docs/firestore/quickstart) - This is a type of document oriented database that is provided by Google via Firebase, it is very simple to use and work with. Personally i have built a couple of web apps using firebaseb firestore and I'm currently using it on a project.
* [**MongoDB**](https://www.mongodb.com/cloud/atlas/lp/try2?utm_source=google&utm_campaign=gs_emea_nigeria_search_core_brand_atlas_desktop&utm_term=mongodb&utm_medium=cpc_paid_search&utm_ad=e&utm_ad_campaign_id=12212624539&gclid=Cj0KCQjwna2FBhDPARIsACAEc_VL7vGvCNKO0cFIhpfUVUKtIbcL66VokARSHSFdltV8qwrjoMRx08caAjltEALw_wcB) - The world's most used document oriented database, Mongodb is cloud database that is provided by the MongoDB organization, it is a complete and robust database, when combined with Mongoosejs you can easily negate some of the drawbacks of document oriented databases, i don't say this very often but i recommend using it over Firestore.
* [**Fauna DB**](https://fauna.com/) - This is a quite a new player in the document oriented database field and it offers more than just document oriented database because you can model relational data, graph data e.t.c but it also keeps things simple and you can only model document data, i pay a lot of attention to this database and i am planning on using it as my database solution for my next app.

That's for that today, i hope you found this useful and you enjoyed reading it, feel free to extend this with the benefits of document oriented database that makes you use them or one of the drawbacks that make you stay away from them. You can also add other document oriented database service providers that you use.

Visit [Netcreed](https://blog.thenetcreed.com) to read more articles like this.