So what's the idea behind
NoSQL database systems again?
Well, the idea in the end is that
we can store data without having to focus
on strict schemas or data structures.
We don't have to define the structure
of a table ahead of time.
We don't have to define the number or types of columns
and we don't have to work with dozens or hundreds of tables
to map out relationships between normalized data records.
Instead, the idea is that
we work with so-called collections,
which are a bit like tables, but unlike tables,
they don't have a fixed structure.
Instead, collections are basically data containers,
you could say, and you can have one
or more collections in your database.
And inside of your collections,
you then have so-called documents.
And documents look a bit like JavaScript objects here.
Though I really wanna emphasize that NoSQL and MongoDB,
what we're going to use in this section here
and in this course in general, is not JavaScript,
it's a database engine, it's a database system.
But it has a lot of similarities with objects in JavaScript
and with how we manage data in Java script.
But of course the difference is that JavaScript
is a programming language and any data we manage there
is only managed in memory as long as our program is running,
whereas NoSQL databases like MongoDB,
our database is where data is stored in files
so that it persists.
So it might look similar when it comes
to some of the data structures,
but it's not a programming language, it's a database system.
So we have these documents,
which are a bit like JavaScript objects,
which we store in collections.
And these documents are simply pieces of data
that have key value pairs,
where the values can be strings, numbers
or even nested objects or lists of data,
arrays you would say in JavaScript.
Now, if we take a closer look at collections and documents,
that is worth noting,
that collections are a bit like tables, as I already said,
but unlike tables in SQL databases,
you don't work with columns and rows,
instead you really have just a data container
where you can hold any kind of documents inside of it.
So there you really kind of a broad mixture off data pieces,
data entities that are stored
in one and the same collection.
And one very important thing to understand here
is that the different documents
that may be stored in the same collection don't have
to have the same structure.
They can be totally different.
They just have to be pieces of data,
like JavaScript objects, that have key value pairs,
but you can have different keys in different documents
that might live in the same collection.
And that gives you a lot of flexibility
because it means that as a developer,
you don't have to plan your entire table
and your data structure ahead of time,
but just as your website might evolve over time,
and at some point of time,
you might decide that you wanna store different pieces
of data than you did in the past,
just as that might happen with NoSQL databases,
you can simply make those adjustments
in the existing database
and just start storing new documents
with a new structure side-by-side with older documents
that might have a different structure.
So that's a lot of extra flexibility,
which you don't have in SQL databases.
Now because we have that flexibility,
we don't normalize our data and it's not the goal
to split our data across a lot of tables.
Instead, when we deal with NoSQL databases
and we have kind of related data,
then we have different options for storing such relations.
NoSQL does support relations
but we store them differently than we do in SQL.
Instead of splitting it across a lot of different tables,
as we would do it in SQL databases, in NoSQL databases,
we very often store related data together in one document.
So we might have nested documents or nested objects inside
of another document or object.
And it could look something like this.
We might have a books collection,
which has multiple book documents.
Here you only see one on the bottom left,
but that's just because I can't fit more on this slide,
but we can have multiple books in there.
And every book document might look like
the one document you see here at the bottom left.
And we have key value pairs here.
And as you can see, some values are just strings,
like the ID or the title of the book,
but then the author, for example, is a nested object.
It's a object instead of the other document.
And it stores information about the author here,
for example, which are more key value pairs,
but in this nested object.
And then we might also have a movies collection
and we might have a relation here as well
because some movies might be based on books.
Now, in such cases,
we might still wanna work with a separate collection
because when you work with NoSQL databases,
you typically store your data such that it best fits
the queries you plan on running.
And it's very likely that you might often fetch
a list of books or a specific book,
and that you often fetch a list of movies
or a specific movie.
But you might not that often fetch all the movies
that belong to one book.
That might sometimes happen,
but probably not as often as your other queries.
And therefore for such cases,
you might just store IDs of movies
in your books collection documents,
as you see it here on the bottom left with the movies key,
and then still have the movie documents
in a separate collection.
So you can split related data across different collections,
but often you will all emerge together.
And in the end,
it comes down to how you plan on querying your data
because that's the most important takeaway here.
With NoSQL databases, like MongoDB,
it's all about thinking about the kind
of queries you're going to execute.
What are you going to do with your data?
And that's quite different from SQL.
With SQL, you plan to store your data in a normalized form,
separated across a lot of tables
and it's all about having this fixed structure.
with NoSQL, it's all about flexibility
and you wanna store your data such that your queries,
your commands that you execute,
can be as short and efficient as possible
so that you don't have to do a lot of merging
and so on, which is quite common for SQL
but not the plan for NoSQL.
So therefore with NoSQL,
you really wanna have efficient queries
and therefore data that's frequently queried together
should be stored together.
And if you have data that's not queried together that often,
you might split it across different collections.
And this might sound quite complex
and it might sound like a case where it's easy
to make mistakes and that's kind of correct,
but on the other hand,
it's also simply something that comes with experience.
And it can have a lot of advantages
that you can optimize your collections
and your data for your queries.
Because with NoSQL,
it is probably easier
to come up with the overall database system
and you don't have to think about the queries ahead of time,
but therefore there on the other hand,
you pay the price by having less flexibility
and in very large applications,
maybe even some performance issues because your queries can
become very complex there with a lot of combined joins.
That's something which you can avoid more easily
when you use NoSQL.
But ultimately using these database systems correctly
all comes down to simply working with them
and gaining some experience and making mistakes.
That's a key part of learning anything anyways.
And therefore now that's the theory,
may be a bit intimidating, but we'll get there step-by-step
throughout this course section
and throughout this course in general,
and therefore now,
let's now have a look at the different options we have
when it comes to working with NoSQL databases.