I read on.
Welcome back.
So and this video we're going to start talking about Mungo day being more details on how we can create
a database in the Mombo the that we install in the previous year.
OK so let's get started.
So here we're going to first talk about modeling in Monga.
DP Right.
Which is an important idea or concept especially in databases in general.
So data Mongo D-B has a flexible schema as it is.
So we don't really have a schema as per se like the normal schema we saw in irregular tables with many
fields.
Right.
We don't really have these the stringent scheme so you can say we have a flexible schema.
Now we're really a scheme about a flexible schema.
And then so you don't have to have all of these fields in the documents in the same collection for the
documents in the same collection.
So they don't need to have the same set of fields or structure and common fields in a collection of
documents may hold different types of data.
So we said that a document that a collection might have a bunch of documents right and each of these
documents might have some of these fields or letters over us one might have for example maybe all of
them have ID.
Right.
Because that's the common thing between all documents.
Maybe this one has name.
This one has last name right.
This one has a date of birth name right.
So they don't necessarily have to have all all of the same field what they necessarily are they're in
the same collection they must represent something or or have similar purpose for example.
In this case you're if they all have names but some of them have date of birth some of them have gender.
Some of them don't have gender.
Some of them are so incomplete information.
Regardless of this all of these documents refer to human beings right or people.
So we can generalize that.
We say that this collection over here represents people.
Right.
But some of the information of these people are known and some of these information are not known.
OK so hopefully this made sense.
Now some consideration while designing scheme.
Right.
And this is really we as we said Mungo Nimi doesn't really have the schema but so whenever I say schema
here we don't think about the same thing as in a table but rather than think as if they're very very
flexible schema that you can change.
OK.
So the first rule is to design your schema according to user requirements and this is very important.
Combined we're going to take an example on this in a few slides.
And so you combine objects into one document.
If you use them together.
Otherwise separate them but make sure there shouldn't be a need of Joines OK.
So what this means is if you have a document should be self-contained.
Right.
You shouldn't have a document that needs to rely on another document.
So if you need another document to rely on this document then put it as an embedded some document in
your so doc too.
And then add the second document over here right in this area over here.
But don't separate documents if you need them to.
If you'll use them together.
Right.
So that's the rule of thumb also duplicate that data because this space is cheap.
But computer time is not cheap.
So what does this mean.
Well nowadays if you look at disk space disk space is very cheap you can buy two terabytes or three
terabytes disks very very cheaply as opposed to compute time.
If you want to you know run run for example a query on your database that might run for five hours.
And that will cost you a lot more than if your just runs for two minutes.
So what this is saying is when you duplicate the data it's easier in the queries so it makes the compute
time low.
So duplicating the data duplicating makes the compute time go down.
But it makes the disk space go up.
Right because you're duplicating some of the data.
So you're adding extra stuff to your disk space.
So it's increasing.
But this is cheap.
This isn't too bad.
This is expensive so we like this degrees.
So always favor duplicating data.
But of course limited right don't just keep duplicating your data everywhere.
But we've always preferred to duplicate the data.
In doing so for example you might put you might have a document here that this document needs but you
also need those documents on its own.
So you would think this document and duplicate it inside if you're inside this document and that's fine.
Right because you're duplicating that data because you need it.
You need to use it with this document also.
OK.
So that's fine.
Also do Joines while right and not on rates that don't do the Joines why you're writing but while reading
optimize your schema for most frequent use cases.
So make sure you cover the most frequent use cases and don't just keep thinking about the corner cases.
Well they are important to consider.
But even if they take a slightly longer time just favor frequent use cases.
So if you have three types of queries in the first career you want to create two or are always done.
Then you should favor your schema towards these queries instead of your theory which maybe is called
one or two times.
And even if it is this query takes for example you know 10 seconds.
If this is micro-seconds this is taking micro-seconds then you're off your overall doing pretty well
right.
And so another thing is do complex aggregation and the schema so don't just for example let's say you
want a SASO aggregation Heeres like some average all these types of different operations.
So don't don't just read write all the records and then loop over every one of them.
For example take the sum or the average.
But instead there are actual queery language that we can use inside the schema that would make us able
to use use aggregation for example some variables.
And it's very they're very fast.
So whenever possible check first if you're trying to do an aggregation like for example count how many
customers bought this product then don't just loop over all the customers and see which one has bought
this customer.
This will be super low.
But instead you can do an aggregation in the scheme and we're going to talk about this like neon in
future videos and this will be a ton easier.
OK so before you do any complex aggregation make sure you can if you can do it in the aggregation language
in the query language.
OK.
OK let's take an example.
So suppose a client needs a database design for his blog or web site so this is a common use case when
explaining databases and see the differences between RDBMS and Mongo db schema design.
Now the Web site has the following requirements.
So if you remember one of the rules we discussed is design your schema according to the user requirements.
So we should always design according to these write rules over here.
So if every post has a unique title description and you are also all of these are unique right so unique.
Let's let's make sure we circle that every post going to have one or more tags.
OK.
So we said in your title description and then that's a post.
So each post can have one or more tags and every post has the same number as the same name of its publisher
and the total number of flights.
Every post has comments given by users along with their name message date time and likes each post their
candidate for each poster can be either 0 or more commas.
OK so these are the user requirements that we collect.
So if you are developing a database or a normal RDBMS then this would look something along the schema
would look something like this so you'd have a table for comment a table for posts and table for the
tags and then each of these tags would have a different ID.
A post ID which is related to it.
Right because each tag is related to some post ID.
And what the name of the tag is right.
And so you here you would notice here there's a one to infinity right so.
And if that you can have an infinite number of tags corresponding to one post right because if you think
about it a post might be tagged with a database.
And Mongo D.B and no sequel right.
So all of these are attacks right.
So you can have multiple tags many tags to one post only here to post this many to one.
And also we can how many comments to one so we have many to 1 and so each comment has a common ID a
post ID by user message date that day the time and light as from the user requirements over here and
the Post has an ID which links to the comments and Tag List has a title and description of your likes
and post by the postman.
OK so hopefully this made sense.
This is usually the normal way we would go along with designing the RDBMS schema right.
But in the case of Mungo D-B it's actually quite different.
So while they Mungo D-B schema design will have one collection post and the following structure.
So we have this outer Jason File here or a document here would be called the post document.
And inside this document there is embed area.
So we have a comments here and then inside these comments we have an array of documents where each of
these documents represents a comment.
So a user message.
They've created unlikes.
So each of these write different comments and we have an array and use a different document.
And so we have an array of documents for a comment.
Also we have an array of documents for text.
So we have an array here of tag document tag document and tag documents you also have the like stored
the you are l by description and title.
OK.
So this made sense.
And this is of course the idea that each post gets and it's unique.
So this is how it would look like and you might be wondering well if I have another post which has for
example this is the same text that I would be duplicating data and that's perfectly fine right because
for example let's say one of the tags here is sequel.
Right.
Then another post I might write might also have sequel and then another post might have sequel.
So I'm actually duplicating the data.
Can't I just create one object to reference inside here.
And the answer is actually it doesn't matter.
In Mongolia we favor duplicating Dega that compu to decrease in favor for decreasing computation time
and make sure that all our documents are self-contained so they don't need to reference outside of documents.
So while showing the data in RDBMS you need to join three tables in non-good D and in non-good the data
will be shown from only one collection.
Right so you don't have to show more than one collidge
OK so how do we create a database and Mongo DBI.
Well to create a database and logwood Eby we use the keyword use and then database name.
So this is used to create a database and the command will create a new database if it doesn't exist
or it will return the existing database.
So if you use for example use ABC.
So no cochère ABC than if you use ABC if we see that database then it's going to switch to ABC database.
If it's not database then it will create a new database called ABC and that is going to switch to that
database.
So the basic syntax of use database is just use use database name.
So let's take an example.
So if you want to create a database with name Majdi be right without this without this brackets here.
So my DBI then we can write then we can use the used data base statement as use my DBI.
So let's go and try that in.
In Mogadishu the server remounting first log in and then we're gonna say use my DVH right so we want
to call it use my day me write my database and then click enter and then it will say here switch to
database my DBI.
So I have done that successful now to check your currently selected database use the command DBI.
So if I go back here I could write DBI and they will tell me that are on the database.
My DBI.
Now I can also if you want check the database list.
Use the.
Use the command show the B's right.
So if I want to see a list of all the date databases then I can do is show Digby's And you'll notice
here that my database is not showing.
So why is that.
Well actually your created database my name is not present in the list because it doesn't have any documents
and so to do that you need to insert at least one document in it.
So I'll just do it.
Database MoVida insert.
I'm just going to insert one document into it.
So let's go back and then I'm going to go D-B dot movie dot insert and then I'm going to make a document
or say name and then the name word correspond to for example x y is that.
So if I click enter then it will tell me the right result is an answer to this.
I've answered it one record and so now if I do show the BS then it should show my database year and
it's 0.00 0 gigabit right because it's only a small size.
Now if we check the database which we saw that when we clicked show it databases than our database were
showing.
And but until you inserted a document then the database is not created.
OK so how do we delete a database so that's how we create a database.
But what about how about we delete a database.
So much would he be D-B that job database command is used to drop an existing database.
So the basic syntax of job database is just to do D-B job database and it deletes the current database
that you're on.
So this will delete the selected data is if you haven't slept in any database then it will delete the
default or all the default test database.
So let's take an example.
So first check the list of variable of available data base by clicking show debuts.
Let's go back and rewrite show on TBS.
And we have an admin config local and my D-B right.
OK.
So now if you want to delete in the new database my baby then we first switch into it.
So we use my DBI.
So it will tell you switched to database my D.B and then now we're going to do our job database.
So we do DVH drop database and then it will tell you dropped my D-B.
OK once so we have successfully deleted this database.
If I write Chaudry means now if I want to see my database showed the BS then you would see that my the
image no longer in the list it's deleted.
So I deleted my database so I will stop here.
And in the next video we'll continue from here on.
So until the next video APIC on.