1 00:00:02,560 --> 00:00:06,730 Now, let's move on to NoSQL databases. 2 00:00:06,730 --> 00:00:09,590 The idea here for storing your data 3 00:00:09,590 --> 00:00:14,480 is a totally different one than in SQL databases. 4 00:00:14,480 --> 00:00:19,480 Instead of working with a lot of tables in NoSQL databases 5 00:00:20,040 --> 00:00:24,160 you typically work with only a few tables. 6 00:00:24,160 --> 00:00:27,410 For example, you could have one big flights table, 7 00:00:27,410 --> 00:00:31,720 and then in there you are storing documents 8 00:00:31,720 --> 00:00:35,740 that contain all the data you wanna store, 9 00:00:35,740 --> 00:00:39,020 so instead of working with columns and rows 10 00:00:39,020 --> 00:00:41,570 as you know it from a SQL database, 11 00:00:41,570 --> 00:00:43,620 here we now store data 12 00:00:43,620 --> 00:00:46,300 for example, in the JSON format, 13 00:00:46,300 --> 00:00:50,140 where we actually have standalone documents 14 00:00:50,140 --> 00:00:54,003 that contain all the data that belongs to a single document. 15 00:00:54,970 --> 00:00:57,970 Now therefore, of course in this concrete example here 16 00:00:57,970 --> 00:01:01,340 we also have a lot of data duplication, 17 00:01:01,340 --> 00:01:04,629 for example, data about the airports is duplicated 18 00:01:04,629 --> 00:01:06,900 across multiple documents, 19 00:01:06,900 --> 00:01:10,410 but this might not necessarily be a problem, 20 00:01:10,410 --> 00:01:14,610 if you are duplicating data that's not changing a lot 21 00:01:14,610 --> 00:01:18,040 and airports data typically doesn't change a lot 22 00:01:18,040 --> 00:01:21,030 because the airport is not suddenly going to move 23 00:01:21,030 --> 00:01:24,280 into a different city then this might be fine 24 00:01:24,280 --> 00:01:28,150 because you never need to touch that duplicate data. 25 00:01:28,150 --> 00:01:32,300 And then the advantage of storing such bigger records 26 00:01:32,300 --> 00:01:34,800 into one table could be, 27 00:01:34,800 --> 00:01:36,580 if I shrink this a bit 28 00:01:36,580 --> 00:01:40,240 that you could store more information in fewer tables 29 00:01:40,240 --> 00:01:45,240 and therefore get more information with fewer queries. 30 00:01:46,010 --> 00:01:48,400 If I'm interested in all the data 31 00:01:48,400 --> 00:01:51,190 that belongs to a special flight code 32 00:01:51,190 --> 00:01:55,010 I could get the entry for a given flight code, 33 00:01:55,010 --> 00:01:56,610 like one, two , three 34 00:01:56,610 --> 00:01:59,990 and if I then fetch the entire data that's attached to it 35 00:01:59,990 --> 00:02:02,740 I automatically get all the start 36 00:02:02,740 --> 00:02:06,020 and destination airport data as well. 37 00:02:06,020 --> 00:02:09,360 I don't need to connect multiple tables for that, 38 00:02:09,360 --> 00:02:13,820 I don't need to run a complex query across multiple tables, 39 00:02:13,820 --> 00:02:17,890 instead I run one query for one field the flight code 40 00:02:17,890 --> 00:02:21,080 and I get all the data that's related to it, 41 00:02:21,080 --> 00:02:23,200 and that can be a huge benefit 42 00:02:23,200 --> 00:02:25,760 because that can simplify your queries 43 00:02:25,760 --> 00:02:30,000 and therefore in the end also improve database performance 44 00:02:30,000 --> 00:02:33,463 because less complex queries have to be executed. 45 00:02:34,700 --> 00:02:38,290 The size of the stored data might become a bit bigger, 46 00:02:38,290 --> 00:02:42,460 but storing big amounts of data is not necessarily a problem 47 00:02:42,460 --> 00:02:45,270 instead, typically the performance bottleneck 48 00:02:45,270 --> 00:02:47,790 is the querying of data, 49 00:02:47,790 --> 00:02:51,610 and that can be simplified with NoSQL databases 50 00:02:51,610 --> 00:02:54,173 because more data is stored together. 51 00:02:55,040 --> 00:02:57,550 So unlike in SQL databases 52 00:02:57,550 --> 00:03:02,500 with NoSQL you don't think in columns and rows, 53 00:03:02,500 --> 00:03:05,800 but instead you have objects or documents 54 00:03:05,800 --> 00:03:07,810 that are stored in a table, 55 00:03:07,810 --> 00:03:11,770 and you also don't have a clearly set schema. 56 00:03:11,770 --> 00:03:12,968 In this example here, 57 00:03:12,968 --> 00:03:15,520 all the entries in the flights table 58 00:03:15,520 --> 00:03:17,610 happened to have the same structure, 59 00:03:17,610 --> 00:03:21,190 but since we have standalone documents, no columns 60 00:03:21,190 --> 00:03:24,900 you can have different structures in different documents 61 00:03:24,900 --> 00:03:26,780 in the same table, 62 00:03:26,780 --> 00:03:29,260 so one of these flights here could, 63 00:03:29,260 --> 00:03:32,500 for example not have a destination airport 64 00:03:32,500 --> 00:03:35,730 and we could still store it in the same database table 65 00:03:35,730 --> 00:03:37,780 as our other flights, 66 00:03:37,780 --> 00:03:39,410 because there is no schema 67 00:03:39,410 --> 00:03:42,023 you have to set and define at the beginning. 68 00:03:42,930 --> 00:03:47,000 So that's the idea behind NoSQL databases. 69 00:03:47,000 --> 00:03:49,570 Now it comes down to personal preference 70 00:03:49,570 --> 00:03:51,780 and knowledge and experiences, 71 00:03:51,780 --> 00:03:55,710 which of the two approaches you find to be more intuitive, 72 00:03:55,710 --> 00:03:59,660 especially if you have worked with SQL databases before 73 00:03:59,660 --> 00:04:02,600 then NoSQL approach can look a bit strange, 74 00:04:02,600 --> 00:04:07,120 but both approaches have their advantages and disadvantages. 75 00:04:07,120 --> 00:04:08,840 And therefore in the next lecture 76 00:04:08,840 --> 00:04:12,570 I wanna compare the two approaches and give you some ideas 77 00:04:12,570 --> 00:04:16,363 on which approach might be best for which situation.