Let's start with documents schema and there's one important question, wasn't mongodb all about
being schemaless and enforcing no schemas? It is, mongodb does not enforce any schemas, your documents
can look the way you want and you can have totally different documents in one and the same collection,
let me show you an example for that.
Here I am again connected to my local and now cleaned up mongodb server,
I simply deleted the data we wrote in the last lectures.
So I got a clean database here, a clean server and I will simply switch to a new database which as you
learned will be created on the fly, on demand.
So I will switch to a new database and I will simply name it shop because imagine we're building the
backend for our online shop and we're now modeling the database for it.
Now in that database, I'll probably have a product collection where I store my product data and there
I will insert one product, a new document therefore with let's say a name and I'll simply name it a book
and a price and the price might be a double,
so a number with a decimal places.
If I now hit enter, this gets acknowledged, this gets inserted and it gets this automatically created
unique _ID field which every document requires
and now we obviously have it in there.
Now let's add another product and what we can do in mongodb is that this product looks totally different,
so there I might have a title which is T-shirt and I might have a seller which is a nested document
let's say, an embedded document with the name of Max and an age of 29.
Now this is a totally different document,
it still could describe a product, though the price is missing but maybe it's free, we don't know
and if I now look into my products here by simply finding all products and pretty printing them, we see
we got these two products in one and the same collection and this is fine,
mongodb will not complain about that,
you can absolutely do that,
you can mix totally different schemas and the schema simply means the structure of one document,
so how does it look like,
which fields does it have,
which types of values do these fields have, that is what is a schema.
So we get totally different structures or schemas as you could call it in one and the same collection
and that is fine.
As I mentioned, mongodb enforces no schemas,
you can mix them but in reality, you will probably have some kind of schema because if you are building
the backend for your online shop, it's in your interest that all your products have a price
for example, that they all have a name which is stored in a field named name
because if you then write some application code, let's say in PHP or in NodeJS and you retrieve your
data from your database,
you obviously want to cycle through that data and output it into a view which you render to the user
and to cycle through your data and access your data,
you need to know in which field which data is stored.
So you will most likely have some kind of schema because you as a developer want it because your application
needs it,
so whilst you're not forced to have a schema, you will probably end up with some kind of structure and that
is the important thing to understand.
You've got the total freedom, total flexibility and if you need it, use it
but in reality, you probably will have to think about how your data looks like because your data will
need some kind of structure so that you could work with it efficiently.