1
00:00:02,250 --> 00:00:05,270
Now you may or may not have a SQL background

2
00:00:05,430 --> 00:00:07,830
but when I started working with mongodb,

3
00:00:07,890 --> 00:00:14,100
there was one thing which I found kind of hard to wrap my head around. Mongodb is a so-called noSQL

4
00:00:14,100 --> 00:00:19,330
solution because it's basically following an opposite concept or philosophy

5
00:00:19,350 --> 00:00:26,250
than all the SQL based databases do. Instead of normalizing data which means storing it, distribute it

6
00:00:26,280 --> 00:00:31,770
across multiple tables where every table has a clear schema and then using a lot of relations, instead

7
00:00:31,770 --> 00:00:36,700
of doing that, mongodb goes for storing data together in a document

8
00:00:36,720 --> 00:00:39,040
and it also doesn't force a schema on you,

9
00:00:39,270 --> 00:00:44,310
so we got no schemas in mongodb. If we have multiple documents in one and the same collection, they

10
00:00:44,310 --> 00:00:46,170
can have different structures,

11
00:00:46,170 --> 00:00:50,080
that is one thing I mentioned in the last video and this is really important,

12
00:00:50,130 --> 00:00:55,500
this can of course lead to messy data but it's still your responsibility as a developer to work with

13
00:00:55,500 --> 00:00:59,870
clean data and to implement a solution that works

14
00:01:00,030 --> 00:01:04,690
but on the other hand, it gives you a lot of flexibility and flexibility is always good.

15
00:01:04,710 --> 00:01:11,280
You can use mongodb for apps that might still evolve, where the exact data requirements are just not

16
00:01:11,280 --> 00:01:12,070
set yet,

17
00:01:12,240 --> 00:01:18,090
you can get started and you can always add data with more information in a collection in the same collection

18
00:01:18,330 --> 00:01:19,730
at a later point of time.

19
00:01:20,610 --> 00:01:22,740
You also work with less relations,

20
00:01:22,740 --> 00:01:26,420
there are some relations and I have old module where I talk about that

21
00:01:26,640 --> 00:01:32,790
but with these embedded documents which I already showed you, one core thing of mongodb indeed is

22
00:01:33,120 --> 00:01:40,320
that you have less tables, so less collections which you connect but instead that you store data together

23
00:01:40,530 --> 00:01:45,180
and this is where the efficiency is derived from. Since data is stored together,

24
00:01:45,180 --> 00:01:51,240
when your application is fetching data, it doesn't need to reach out to collection A, merge it with

25
00:01:51,240 --> 00:01:59,430
collection B, merge it with collection C, instead it goes to collection A then mongodb has a very efficient

26
00:02:00,240 --> 00:02:06,240
querying mechanism behind the scenes so that it can go through all the data very fast when looking for

27
00:02:06,360 --> 00:02:07,710
a specific document,

28
00:02:07,860 --> 00:02:12,330
so this will be super fast and then it finds that document and it's done,

29
00:02:12,330 --> 00:02:14,970
it doesn't need to do any merging most of the time.

30
00:02:15,180 --> 00:02:19,620
So this is really where the speed, the performance and flexibility comes from

31
00:02:19,620 --> 00:02:25,080
and this hopefully speaks for itself that this can be useful when building applications

32
00:02:25,320 --> 00:02:31,380
and this is also why noSQL solutions and amongst them most of all mongodb, is super popular

33
00:02:31,620 --> 00:02:38,250
for read write heavy applications, applications with a lot of workload, applications that store a lot

34
00:02:38,250 --> 00:02:43,200
of data, let's say smart devices which send some sensor data every second,

35
00:02:43,320 --> 00:02:49,320
for such applications but also for building an online shop or a blog, mongodb is an amazing

36
00:02:49,320 --> 00:02:53,590
solution due to the performance and the flexibility it gives you.