1. Advantages and limitations of document databases
Congratulations on completing the exercises! In this lesson, we will deepen our knowledge by studying the advantages and limitations of document databases.
2. Advantages - flexibility
Let's start with the advantages. Document databases are flexible. As we learned in the previous lesson,
we don't need to predefine the schema.
Documents can vary over time,
but with document databases, we will avoid complex migrations when changes happen.
With embedded documents, we don't need to join tables like in relational databases. The joining process can be potentially time-consuming if the tables are large or if we are joining many tables,
so we can get better times with document databases.
The flexibility advantage is one of the first reasons why developers choose document databases for their projects.
3. Advantages - intuitive for developers
For developers, working with documents is very intuitive
and a natural way to work with.
JSON documents are human-readable, being a friendly way to represent the data.
Documents can map to the objects in the code,
which implies less coding
and a simpler and faster development task. For example, we can have in our code an object with properties representing a user. This object can have the same structure that a document with the information of a user.
Programmers can start coding and storing objects as documents are created.
For new developers, this way of programming can be easier.
4. Advantages - horizontal scalability
As we saw with key-value databases, document databases can scale horizontally
by using the sharding technique.
5. Limitations - more responsibility
On the other hand, document databases have some limitations.
As they are schemaless, we will have to be more responsible and care about data in the application code.
For example, if the email account is always required when signing up a user, we will have to check in our code if this information has been received. This scenario is simple, but more complex ones can occur.
Another point to take care of is redundant data. We may introduce redundancy for optimizing, but we must remember which data is redundant. Let's suppose that we need to display a customer name in several parts of our application, so we decide to duplicate the name in different documents to optimize the queries.
If we need to modify the name, we will have to remember that we must change it in all the documents.
6. Let's practice!
Great job! Let's take some exercises before studying the scenarios where document databases are suitable.