- [Instructor] When I start a new project,
I always spend a lot of time
thinking about which technology to use
and with databases today,
you have a lot of choices
and of course,
there are a lot of use cases
where document databases
make your life easier,
but there are also cases
where maybe a relational database
might be better.
So let's start with use cases
where you should avoid
document databases.
First of all, if your data is
highly structured and related
think of a tax or billing system.
Also, if data integrity's is key
and has to be enforced
at any given time
and connected to that,
if many different applications
manipulate the data
and you want to make sure
that the data is consistent
and this should be taken care of
by the database system itself.
So what would be good use cases
for document databases?
For instance,
if the data is unstructured
or semi-structured.
Think about an item management system
where some items have some properties
and some items have other properties
or you collect data
from different sources
like the metric system
and you store the metrics
then in the database
and the metrics are largely different
or if you want high write performance.
Before we talked about consistency,
taking care of this consistency,
of course, comes with
some performance penalty
and this document databases
don't care so much about consistency,
they're usually faster
when it's about writing data
to the database.
Also, if you want to scale out.
So if you want to distribute
the data and the load
to different machines.
Again, if the system does not have
to look at consistency
and locking of tables,
this is of course way fast
and easier to achieve
with document databases
and all those document databases
come usually with very powerful tooling
for clustering the data.
In this chapter, we will use MongoDB
to store the items of a shop
and before we do that
we will quickly extend
our Mexican application with MongoDB,
just to get a little bit
of a grip on MongoDB first.