Let's have a look at that schema thing and let's think about the options we have.
So obviously, we can have a totally chaotic approach as I showed you in that last little example with
totally different documents and one and the same collection or we follow a SQL worldlike approach
where we make sure that all elements, all entries have exactly the same schema and there is no extra
entry on any document.
So we got the whole bandwidth and we of course, we also got some shades in between,
so in the chaos world, we basically got what we just saw in the little example,
we got maybe a products collection with totally different products in there,
so that is possible in mongodb but it's probably not what you need or what you'll use in reality.
Maybe you're somewhere in between,
you got some kind of schema, for example here
all my products have a title and a price but you got some extra information on some of your documents,
so there is maybe some extra data on some documents but the general schema is the same
and there probably are some core fields which exist on every document.
Well or you got the other extreme where all documents have exactly the same structure, like here.
Now anything is possible here, you can go with any of the three solutions or any step in-between depending
on how you need it in your application
but in reality, I guess either the approach on the right or most often the one in the middle is what you
will see in reality
because there, you use the best of both worlds.
You have some structure because your usecase, your application probably needs it but you also take advantage
of the flexibility mongodb gives you so that you can store extra information, that by the way is also
possible in the SQL world, there maybe you would have a null value for some fields,
well in the middle world, you simply omit a field if you have no data and you assign a value to the field
if you do. So that is really a mixture,
in the end go with whatever works for you,
the case in the middle and the case on the right are the more realistic ones or the ones you see more
often
in reality I guess though. Back in my collection,
let me quickly clear my products here
with deleteMany and there I'll simply pass an empty pair of curly braces to delete all my entries,
so that now it's empty
and now in there, let me again insert some products, insertOne and I want to to show the two approaches,
which are the most realistic ones.
Let's go with the middle approach first, which might be the one you see most often,
there you have a name like a book,
you got a price like 12.99 and that's maybe it for the first product and then you enter another
product and that product also will have a name and a price because these are probably some core fields
which every product needs in your application because on the page you rendered to your users, on a website
.
let's say, you probably want to show at least a name and a price.
So for our other product, a T-shirt, simply the value changes
but the fields are the same and the names of these fields also are,
whoops, I hit enter accidentally,
of course I should enter price here like 20.99.
So now if I look into my products here and I pretty print that, we see
both elements are in there. Now
this is the case on the right, the SQL world,
we got exactly the same structure, just the values differ.
Now you might have another product,
let's say a computer and of course that also has another price like this but this might now also
have an extra field, details maybe. Let's say in your shop,
not every element has details because maybe a book for some reason doesn't require details,
obviously you could argue a book and a T-shirt also have detail data but this is just an example, let's
say our computer has some details because there, we basically have the CPU and that is the text where
we have Intel i7, some build number, like this.
If I add this and now I find all my documents, we are in the middle world,
we got a core structure which every document fulfills, like a name and a price exists on every document,
a little side note here is that the price actually does not always have the same kind of data,
it looks like it always has a number and that is true but we switch between a double number, so number
with decimal places and an integer, a number without decimal places but that's a side note,
I'll come back to data types.
So generally we have the same though, name and price but then we get some extra information on one product
and that might be something that works for your application too because there, you could of course
have some code which always displays the name and the price but only displays the details
if available and therefore we can reflect this in our data and we now are in that middle column of the last
slide.
So this is one of the more realistic cases you'll have in mongodb
and this is a totally fine way of using it.
Well all the use cases were fine but this is one you'll encounter in practice too
or of course, you have exactly the same fields for all your products. Just to showcase this really quick,
I'll again go into my products database and delete all my products in there with deleteMany and let's
say we want to have that same structure we had before but now, we want to have that in a way where all
documents have exactly the same fields and that is possible,
if I repeat my insert commands here for the book, we would simply set details equal to null, null is a
value which you can assign to indicate that
well there is no value but there is the field available then.
So if we do that and we do the same for the tshirt here,
so we also have the details set to null there and I then also enter my computer, if I now find all products
and pretty print them, we see the difference to before is that we still have no detailed data for
the first two products, only for the third one
but now we still have that field in there. That is the more SQL-ish approach I'd say because the structure
is now exactly equal in all documents except for that number thing which I mentioned, the price is a different
type of number
but otherwise it's exactly the same structure
and this might also be an approach you use because you like the clarity of having exactly the same fields
everywhere and you simply indicate that no value is available by setting the value to null.
Now here you can take either approach,
it's probably a bit more MongoDB-ish to simply get rid of details if it holds no value
but ultimately this is also up to you and you could take this route too.
There is no single best practice here,
you can go with whichever approach works better for you or whichever approach you personally prefer.