1
00:00:04,652 --> 00:00:11,190
Думаю, твоя голова заражена мангузами или монгузами?

2
00:00:11,190 --> 00:00:16,500
Ну, я не английский майор, так что я понятия не имею, что такое множественное число.

3
00:00:16,500 --> 00:00:22,770
В любом случае, это подводит нас к теме этой лекции, население Мангуста.

4
00:00:22,770 --> 00:00:25,120
Что такое популяция Мангуста и

5
00:00:25,120 --> 00:00:29,800
как она полезна в нашем экспресс-приложении?

6
00:00:29,800 --> 00:00:31,190
Давай поговорим об этом дальше.

7
00:00:33,100 --> 00:00:38,275
Как мы поняли, базы данных документов, базы данных NoSQL,

8
00:00:38,275 --> 00:00:41,767
не разработаны с учетом отношений.

9
00:00:41,767 --> 00:00:46,570
Все, что вам нужно в документе, хранится полностью внутри документа.

10
00:00:46,570 --> 00:00:53,650
Ну, это в значительной степени то, как вещи работают с базами данных NoSQL, такими как MongoDB.

11
00:00:53,650 --> 00:00:58,490
Таким образом, у вас нет поддержки отношений,

12
00:00:58,490 --> 00:01:03,065
с которыми вы могли бы быть более знакомы из мира реляционных баз данных.

13
00:01:03,065 --> 00:01:08,060
Там, где у вас есть записи, а затем записи могут ссылаться на другие записи и так далее.

14
00:01:08,060 --> 00:01:12,510
И затем вы присоединяетесь, чтобы присоединиться к информации из записей и так далее.

15
00:01:12,510 --> 00:01:17,030
Таким образом, такая поддержка не существует в базах данных NoSQL,

16
00:01:17,030 --> 00:01:19,010
по крайней мере, в значительной степени.

17
00:01:19,010 --> 00:01:25,120
MongoDB предпринял несколько шагов в этом направлении, даже с базами данных NoSQL.

18
00:01:25,120 --> 00:01:31,030
Но в целом базы данных документов предполагают, что все документы являются автономными.

19
00:01:31,030 --> 00:01:36,740
Таким образом, что означает, что вся информация, которая требуется, находится в пределах одного документа.

20
00:01:36,740 --> 00:01:41,270
Теперь, конечно, бывают ситуации, когда у вас есть другие документы, которые

21
00:01:41,270 --> 00:01:43,657
уже содержали информацию.

22
00:01:43,657 --> 00:01:47,561
И вы можете извлечь эту информацию в существующий документ,

23
00:01:47,561 --> 00:01:50,580
а не дублировать эту информацию.

24
00:01:50,580 --> 00:01:57,390
Таким образом, это где MongoDB или Mongoose,

25
00:01:57,390 --> 00:02:04,290
позволяет хранить ссылки на другие документы в текущем документе.

26
00:02:04,290 --> 00:02:08,953
Ссылка на другой документ делается с помощью ObjectID этого

27
00:02:08,953 --> 00:02:10,125
другого документа.

28
00:02:10,125 --> 00:02:14,773
Теперь, если это так, то Mongoose позволяет вам выполнить способ

29
00:02:14,773 --> 00:02:19,588
взятия информации из другого документа, а затем вложение ее в

30
00:02:19,588 --> 00:02:25,010
правильный документ, используя поддержку популяции Mongoose.

31
00:02:25,010 --> 00:02:28,230
Это то, что мы обсудим чуть более подробно.

32
00:02:28,230 --> 00:02:33,227
Сам Mongoose, как мы понимаем, будучи модулем, построенным

33
00:02:33,227 --> 00:02:38,336
поверх MongoDB, не имеет явной поддержки для

34
00:02:38,336 --> 00:02:43,135
соединений, как мы говорим о соединениях в мире SQL.

35
00:02:43,135 --> 00:02:48,471
Чтобы понять, как эта ссылка на другой документ в документе помогает нам и

36
00:02:48,471 --> 00:02:53,210
как она на самом деле структурирована, давайте рассмотрим пример.

37
00:02:53,210 --> 00:02:58,420
В этом примере мы рассмотрим документ блюд, который мы

38
00:02:58,420 --> 00:03:01,210
использовали в нашем упражнении.

39
00:03:01,210 --> 00:03:04,540
В документах посуды, которые мы храним на стороне сервера,

40
00:03:04,540 --> 00:03:07,590
мы заметили, что мы также храним комментарии.

41
00:03:07,590 --> 00:03:12,366
И в комментариях мы также сохраняем поле автора в комментариях.

42
00:03:12,366 --> 00:03:16,750
И поле автора явно содержит имя человека, который

43
00:03:16,750 --> 00:03:19,890
представил этот конкретный комментарий.

44
00:03:19,890 --> 00:03:24,961
Теперь, так как у нас уже есть документ пользователя

45
00:03:24,961 --> 00:03:30,453
в нашей базе данных, как мы видели в этом модуле.

46
00:03:30,453 --> 00:03:35,151
Мы расширили наш экспертный сервер для поддержки пользователей и, таким образом,

47
00:03:35,151 --> 00:03:40,440
вы можете зарегистрировать пользователя и что вы можете аутентифицировать пользователей и так далее.

48
00:03:40,440 --> 00:03:45,790
Таким образом, документ пользователя может содержать дополнительную информацию о пользователе уже.

49
00:03:46,810 --> 00:03:49,302
И поэтому, когда комментарий публикуется пользователем,

50
00:03:49,302 --> 00:03:53,043
вместо того, чтобы хранить имя пользователя в самом комментарии,

51
00:03:53,043 --> 00:03:57,360
почему бы не иметь ссылку на конкретного пользователя, который опубликовал комментарий?

52
00:03:58,360 --> 00:04:02,570
Это полезно не только с точки зрения возможности иметь

53
00:04:02,570 --> 00:04:07,680
дело с тем, что этот комментарий опубликован конкретным пользователем.

54
00:04:07,680 --> 00:04:13,934
Позже мы увидим, что если вам нужно разрешить пользователям изменять или

55
00:04:13,934 --> 00:04:19,126
удалять документы, вы можете ограничить вид

56
00:04:19,126 --> 00:04:24,436
работы конкретного пользователя только теми комментариями,

57
00:04:24,436 --> 00:04:28,937
которые этот конкретный пользователь опубликовал ранее.

58
00:04:28,937 --> 00:04:36,649
Несмотря на то, что мы используем вложенные документы в нашем документе Mongo.

59
00:04:36,649 --> 00:04:42,292
Если мы можем ссылаться на другой документ в поддокументе с помощью ObjectID,

60
00:04:42,292 --> 00:04:45,415
то Mongo помогает нам сделать популяцию этой

61
00:04:45,415 --> 00:04:50,450
информации из другого документа в текущий документ.

62
00:04:50,450 --> 00:04:54,370
Вот где население Мангуста приходит нам на помощь.

63
00:04:54,370 --> 00:04:57,770
Продолжая эту идею, позвольте мне показать вам подробный

64
00:04:57,770 --> 00:05:02,600
пример из схемы комментариев, которую мы определили ранее.

65
00:05:02,600 --> 00:05:06,850
Таким образом, в CommentSchema у нас уже есть поле рейтинга и

66
00:05:06,850 --> 00:05:10,080
поле комментария, которое мы там уже указали.

67
00:05:10,080 --> 00:05:13,320
Раньше у нас было поле автора.

68
00:05:13,320 --> 00:05:18,133
Для поля автора ранее мы сохраняли автора в

69
00:05:18,133 --> 00:05:23,270
виде строки и, Значение по умолчанию также для автора.

70
00:05:23,270 --> 00:05:28,285
Теперь в хранении автора в виде строки типа, если мы теперь превратим

71
00:05:28,285 --> 00:05:34,200
автора в тип Mongoose.Schema.Types.ObjectID.

72
00:05:34,200 --> 00:05:39,350
Это означает, что поле автора теперь будет содержать ObjectID,

73
00:05:39,350 --> 00:05:42,870
который является ссылкой на документ пользователя.

74
00:05:42,870 --> 00:05:46,090
Как убедиться, что это ссылается на документ пользователя?

75
00:05:46,090 --> 00:05:51,500
Таким образом, это дополнительное свойство под названием ref, которое указывает, что

76
00:05:51,500 --> 00:05:56,160
схема документа, который вы ссылаетесь здесь, имеет тип, пользователь,

77
00:05:56,160 --> 00:05:59,590
схема и модель, которые мы уже добавили ранее.

78
00:05:59,590 --> 00:06:05,144
Таким образом, в этом случае схема комментариев теперь расширена для хранения информации об авторе,

79
00:06:05,144 --> 00:06:08,706
но информация об авторе находится в виде ObjectID.

80
00:06:08,706 --> 00:06:15,480
Которая является ссылкой на пользовательский документ, который уже хранится в нашей базе данных.

81
00:06:15,480 --> 00:06:17,750
Итак, как это нам поможет?

82
00:06:17,750 --> 00:06:22,667
Вот где, как я сказал, население Мангуста приходит к нам на помощь.

83
00:06:22,667 --> 00:06:25,120
Так как работает население Мангуста?

84
00:06:25,120 --> 00:06:30,150
С популяцией Mongoose, способ работы популяции Mongoose заключается в том, что

85
00:06:30,150 --> 00:06:35,363
он автоматически заменяет указанные пути в текущем документе.

86
00:06:35,363 --> 00:06:40,850
Который имеет ссылку на другой документ по информации из этого другого документа.

87
00:06:40,850 --> 00:06:46,282
Таким образом, в схеме комментариев, например, у вас есть поле автора, которое

88
00:06:46,282 --> 00:06:53,070
ссылается на ObjectID документа пользователя, который уже находится в вашей базе данных.

89
00:06:53,070 --> 00:06:58,963
Таким образом, с популяцией Mongoose, когда вы просите Mongoose

90
00:06:58,963 --> 00:07:03,820
заполнить этот документ блюдо, то он будет заполнять информацию об авторе в поле комментария

91
00:07:03,820 --> 00:07:05,240
из документа пользователя.

92
00:07:05,240 --> 00:07:09,447
Таким образом, информация о конкретном авторе, на который ссылается там, будет

93
00:07:09,447 --> 00:07:12,130
извлечена и добавлена в ваш документ блюдо.

94
00:07:12,130 --> 00:07:16,820
И составный документ будет построен, а затем отправлен вам обратно.

95
00:07:16,820 --> 00:07:19,370
Как мы можем обеспечить, чтобы это произошло?

96
00:07:19,370 --> 00:07:25,020
Вот где перекрестные ссылки с ObjectID, как мы видели, помогают нам.

97
00:07:25,020 --> 00:07:30,890
Как население на самом деле происходит в коде?

98
00:07:30,890 --> 00:07:33,350
Взгляните на то, как мы будем заполнять,

99
00:07:33,350 --> 00:07:38,090
например, документ блюд, который мы только что видели ранее.

100
00:07:38,090 --> 00:07:43,650
Раньше мы делали блюда. Найти все блюда в нашей базе.

101
00:07:43,650 --> 00:07:48,645
Теперь, как только вы найдете документ Блюда, вы можете сказать заполнить.

102
00:07:48,645 --> 00:07:52,647
А затем поставлять внутри заполненной, в качестве

103
00:07:52,647 --> 00:07:56,130
параметра, конкретное поле, которое необходимо заполнить.

104
00:07:56,130 --> 00:07:59,380
Итак, здесь мы указываем comments.author.

105
00:07:59,380 --> 00:08:02,270
Теперь ожидается, что поле comments.author

106
00:08:02,270 --> 00:08:06,550
на самом деле является OjectID, который ссылается на документ пользователя.

107
00:08:06,550 --> 00:08:10,502
И вот как мы уже настроили нашу схему комментариев.

108
00:08:10,502 --> 00:08:16,418
Таким образом, этот вызов заполнения, который мы выполняем здесь, затем пойдет и

109
00:08:16,418 --> 00:08:24,937
извлечет из базы данных каждую запись автора или запись пользователя.

110
00:08:24,937 --> 00:08:27,457
А затем возьмите этот документ пользователя и

111
00:08:27,457 --> 00:08:33,505
заполняет его в документ посуды, чтобы построить составной документ отсюда.

112
00:08:33,505 --> 00:08:35,525
И после этого, конечно,

113
00:08:35,525 --> 00:08:39,579
есть последующая обработка данных, которые вы получили.

114
00:08:39,579 --> 00:08:44,640
И затем ответ или возврат данных клиенту может произойти в этот момент.

115
00:08:44,640 --> 00:08:49,110
Но, конечно, позвольте мне предупредить вас, что эта операция

116
00:08:49,110 --> 00:08:52,020
с населением — непростая задача для сервера.

117
00:08:52,020 --> 00:08:56,825
Потому что каждое блюдо, вам придется изучить каждый комментарий.

118
00:08:56,825 --> 00:09:01,385
Затем для каждого комментария вам нужно узнать их ObjectID для

119
00:09:01,385 --> 00:09:02,034
пользователя.

120
00:09:02,034 --> 00:09:04,580
Затем вы идете и извлекаете этот документ пользователя, а

121
00:09:04,580 --> 00:09:07,203
затем заполняете его внутри документа блюдо.

122
00:09:07,203 --> 00:09:09,329
И затем, это должно повторяться для

123
00:09:09,329 --> 00:09:13,113
каждого комментария, который содержится в этом документе Блюда.

124
00:09:13,113 --> 00:09:18,437
Это по существу означает, что на стороне сервера потребуется гораздо больше времени

125
00:09:18,437 --> 00:09:23,720
для завершения запроса и отправки информации обратно на клиентскую сторону.

126
00:09:23,720 --> 00:09:31,020
Поэтому я бы предложил, чтобы вы использовали заполнение очень разумно.

127
00:09:31,020 --> 00:09:35,410
Вы должны использовать его только в тех случаях, когда вам действительно нужна эта информация.

128
00:09:36,590 --> 00:09:42,529
Если, например, вы просто создаете меню для своего ресторана.

129
00:09:42,529 --> 00:09:46,522
Когда вы просто создаете меню для своего ресторана,

130
00:09:46,522 --> 00:09:51,267
вам может не понадобиться вообще заполнять информацию об авторе каждого

131
00:09:51,267 --> 00:09:54,010
комментария в документе комментария.

132
00:09:54,010 --> 00:09:57,270
Потому что, когда вы просто рендеринг меню для вашего ресторана,

133
00:09:57,270 --> 00:10:01,730
вы не будете показывать комментарии к этому конкретному блюду.

134
00:10:01,730 --> 00:10:06,457
Но вместо этого, если пользователь изучает конкретное блюдо и

135
00:10:06,457 --> 00:10:09,804
хочет увидеть комментарии в этот момент,

136
00:10:09,804 --> 00:10:13,660
вы можете выполнить запрос на стороне сервера.

137
00:10:13,660 --> 00:10:19,383
А затем получить информацию комментария с другой информацией автора,

138
00:10:19,383 --> 00:10:24,540
заполненной в и получить ее для использования в пределах нашей клиентской стороны.

139
00:10:24,540 --> 00:10:30,240
Так что опять же, заполнение является прекрасным способом делать вещи, когда

140
00:10:30,240 --> 00:10:35,610
это необходимо, но использовать его очень справедливо, только когда вам действительно требуется информация.

141
00:10:35,610 --> 00:10:38,370
Таким образом, гибкость, которая обеспечивает

142
00:10:38,370 --> 00:10:42,540
нам заполнение, является тот факт, что нам не нужно заполнять, когда нам не нужно.

143
00:10:42,540 --> 00:10:46,990
Но мы можем заполнить информацию, когда нам действительно нужна эта информация.

144
00:10:48,030 --> 00:10:51,450
С этим быстрым пониманием популяции Мангуста,

145
00:10:51,450 --> 00:10:57,280
давайте перейдем к упражнению, где мы будем изменять схему Блюда,

146
00:10:57,280 --> 00:10:59,840
схему комментариев в схеме Блюда.

147
00:10:59,840 --> 00:11:04,730
А затем использовать Mongoose заполнить информацию в наших блюдах,

148
00:11:04,730 --> 00:11:09,255
когда мы возвращаем информацию о блюде на стороне сервера.

149
00:11:09,255 --> 00:11:15,745
Кроме того, это также означает, что при добавлении комментария к определенному блюду,

150
00:11:16,775 --> 00:11:22,210
автор информации комментария должен быть захвачен на стороне сервера.

151
00:11:22,210 --> 00:11:26,079
Так получилось, что, как мы разработали наши серверы, у

152
00:11:26,079 --> 00:11:29,740
нас уже есть эта информация, предоставляемая нам.

153
00:11:29,740 --> 00:11:34,870
Когда мы аутентифицируем пользователя, информация пользователя уже загружается в каждый

154
00:11:34,870 --> 00:11:37,580
запрос, который приходит со стороны клиента.

155
00:11:37,580 --> 00:11:41,200
И поэтому они используют эту пользовательскую информацию, доступную нам.

156
00:11:41,200 --> 00:11:46,170
Поэтому, когда мы публикуем комментарий на стороне сервера, мы также

157
00:11:46,170 --> 00:11:52,370
захватим идентификатор пользователя, а затем сохраним его в поле автора схемы комментария.

158
00:11:52,370 --> 00:11:55,430
Это должно быть сделано автоматически на стороне сервера.

159
00:11:55,430 --> 00:12:00,740
Клиенту не следует разрешать явно заполнять поле автора.

160
00:12:00,740 --> 00:12:04,348
Но серверная сторона должна проверять пользователя, и только для

161
00:12:04,348 --> 00:12:10,020
пользователей, которые вошли в систему, вы разрешаете им, в первую очередь, публиковать комментарии.

162
00:12:10,020 --> 00:12:12,688
А затем, когда они

163
00:12:12,688 --> 00:12:18,392
будут публиковать комментарии, вы автоматически заполняете поле автора для этого документа комментария,

164
00:12:18,392 --> 00:12:23,740
заменив поле автора на ObjectID пользователя.

165
00:12:23,740 --> 00:12:25,920
Теперь, в упражнении, вы увидите, как я делаю это.

166
00:12:25,920 --> 00:12:30,780
Так что следите за этой конкретной вещью в упражнении.

167
00:12:30,780 --> 00:12:33,245
С этим мы завершим эту лекцию,

168
00:12:33,245 --> 00:12:38,109
давайте перейдем к упражнению, чтобы изучить использование популяции Мангуста.

169
00:12:38,109 --> 00:12:44,079
[ МУЗЫКА]