1
00:00:00,000 --> 00:00:04,652
(MUSIK)

2
00:00:04,652 --> 00:00:11,190
Ich schätze, dein Kopf ist von Mungos befallen oder ist es Mongeese?

3
00:00:11,190 --> 00:00:16,500
Nun, ich bin kein Englisch-Major, also habe ich keine Ahnung, was der Plural ist.

4
00:00:16,500 --> 00:00:22,770
Auf jeden Fall bringt uns das zum Thema dieser Vorlesung, Mungo Bevölkerung.

5
00:00:22,770 --> 00:00:25,120
Was genau ist Mongoose Bevölkerung und

6
00:00:25,120 --> 00:00:29,800
wie ist es nützlich in unserer Express-Anwendung?

7
00:00:29,800 --> 00:00:31,190
Lass uns als Nächstes darüber reden.

8
00:00:33,100 --> 00:00:38,275
Wie wir erkannt haben,

9
00:00:38,275 --> 00:00:41,767
sind Dokumentdatenbanken, die NoSQL-Datenbanken, nicht mit Relationen im Auge.

10
00:00:41,767 --> 00:00:46,570
Alles, was Sie in einem Dokument benötigen, wird vollständig im Dokument gespeichert.

11
00:00:46,570 --> 00:00:53,650
Nun, das ist so ziemlich die Art, wie die Dinge mit NoSQL-Datenbanken wie MongoDB arbeiten.

12
00:00:53,650 --> 00:00:58,490
Sie haben also keine Unterstützung für Beziehungen, die Sie

13
00:00:58,490 --> 00:01:03,065
aus der relationalen Datenbankwelt besser kennen könnten.

14
00:01:03,065 --> 00:01:08,060
Wo Sie Datensätze haben und dann Datensätze können auf andere Datensätze verweisen und so weiter.

15
00:01:08,060 --> 00:01:12,510
Und dann tun Sie Joins, um die Informationen aus den Datensätzen zu verbinden und so weiter.

16
00:01:12,510 --> 00:01:17,030
Diese Art von Unterstützung existiert also nicht in NoSQL-Datenbanken,

17
00:01:17,030 --> 00:01:19,010
zumindest zu einem großen Teil.

18
00:01:19,010 --> 00:01:25,120
MongoDB hat einige Schritte in diese Richtung unternommen, sogar mit den NoSQL-Datenbanken.

19
00:01:25,120 --> 00:01:31,030
Im Allgemeinen erwarten Dokumentdatenbanken jedoch, dass alle Dokumente in sich geschlossen sind.

20
00:01:31,030 --> 00:01:36,740
Das bedeutet also, dass sich alle erforderlichen Informationen innerhalb desselben Dokuments befinden.

21
00:01:36,740 --> 00:01:41,270
Nun gibt es natürlich Situationen, in denen Sie andere Dokumente haben, die

22
00:01:41,270 --> 00:01:43,657
bereits die Informationen enthalten.

23
00:01:43,657 --> 00:01:47,561
Möglicherweise möchten Sie diese Informationen in Ihr vorhandenes Dokument abrufen,

24
00:01:47,561 --> 00:01:50,580
anstatt diese Informationen zu duplizieren.

25
00:01:50,580 --> 00:01:57,390
Dies ist also, wo MongoDB oder Mongoose,

26
00:01:57,390 --> 00:02:04,290
ermöglicht es Ihnen, Verweise auf andere Dokumente in einem aktuellen Dokument zu speichern.

27
00:02:04,290 --> 00:02:08,953
Der Verweis auf das andere Dokument erfolgt mithilfe der ObjectID des

28
00:02:08,953 --> 00:02:10,125
anderen Dokuments.

29
00:02:10,125 --> 00:02:14,773
Nun, wenn das der Fall ist, dann können Sie Mongoose eine Möglichkeit durchführen,

30
00:02:14,773 --> 00:02:19,588
die Informationen aus dem anderen Dokument zu nehmen und dann in das

31
00:02:19,588 --> 00:02:25,010
richtige Dokument einzufügen, indem Sie die Mungo Populationsunterstützung verwenden.

32
00:02:25,010 --> 00:02:28,230
Das ist es, was wir noch ein wenig ausführlicher diskutieren werden.

33
00:02:28,230 --> 00:02:33,227
Mongoose selbst, wie wir erkennen, ein Modul, das

34
00:02:33,227 --> 00:02:38,336
auf MongoDB gebaut ist, hat keine explizite Unterstützung für

35
00:02:38,336 --> 00:02:43,135
Joins, die Art und Weise, wie wir über Joins in der SQL-Welt sprechen.

36
00:02:43,135 --> 00:02:48,471
Um zu verstehen, wie uns diese Referenz auf das andere Dokument in einem Dokument hilft und

37
00:02:48,471 --> 00:02:53,210
wie es tatsächlich strukturiert ist, werfen wir einen Blick auf ein Beispiel.

38
00:02:53,210 --> 00:02:58,420
In diesem Beispiel werden wir uns das Geschirr Dokument ansehen, das wir

39
00:02:58,420 --> 00:03:01,210
in unserer Übung verwendet haben.

40
00:03:01,210 --> 00:03:04,540
In den Geschirr Dokumenten, die wir auf der Serverseite speichern,

41
00:03:04,540 --> 00:03:07,590
haben wir bemerkt, dass wir auch die Kommentare speichern.

42
00:03:07,590 --> 00:03:12,366
Und innerhalb der Kommentare speichern wir auch ein Autorenfeld innerhalb der Kommentare.

43
00:03:12,366 --> 00:03:16,750
Und Autorenfeld enthält explizit den Namen der Person, die

44
00:03:16,750 --> 00:03:19,890
diesen bestimmten Kommentar eingereicht hat.

45
00:03:19,890 --> 00:03:24,961
Nun, da wir bereits ein Benutzerdokument

46
00:03:24,961 --> 00:03:30,453
in unserer Datenbank haben, wie wir in diesem Modul gesehen haben.

47
00:03:30,453 --> 00:03:35,151
Wir hatten unseren Experten-Server erweitert, um Benutzer zu unterstützen und damit

48
00:03:35,151 --> 00:03:40,440
können Sie einen Benutzer registrieren und Benutzer authentifizieren und so weiter.

49
00:03:40,440 --> 00:03:45,790
So kann das Benutzerdokument bereits zusätzliche Informationen über den Benutzer enthalten.

50
00:03:46,810 --> 00:03:49,302
Und wenn ein Kommentar vom Benutzer gepostet wird,

51
00:03:49,302 --> 00:03:53,043
anstatt den Namen des Benutzers innerhalb des Kommentars selbst zu speichern,

52
00:03:53,043 --> 00:03:57,360
warum nicht einen Verweis auf den bestimmten Benutzer haben, der den Kommentar gepostet hat?

53
00:03:58,360 --> 00:04:02,570
Dies ist nicht nur im Hinblick auf

54
00:04:02,570 --> 00:04:07,680
die Tatsache hilfreich, dass dieser Kommentar vom jeweiligen Benutzer gepostet wird.

55
00:04:07,680 --> 00:04:13,934
Später werden wir sehen, dass Sie, wenn Sie Benutzern erlauben müssen

56
00:04:13,934 --> 00:04:19,126
, Dokumente zu ändern oder zu löschen, die Art der

57
00:04:19,126 --> 00:04:24,436
Operation eines bestimmten Benutzers nur auf die Kommentare beschränken möchten

58
00:04:24,436 --> 00:04:28,937
, die dieser bestimmte Benutzer zuvor gepostet hat.

59
00:04:28,937 --> 00:04:36,649
Obwohl wir Unterdokumente innerhalb unseres Mongo-Dokuments verwenden.

60
00:04:36,649 --> 00:04:42,292
Wenn wir ein anderes Dokument im Unterdokument mit ObjectIDs

61
00:04:42,292 --> 00:04:45,415
referenzieren können, hilft Mongo uns, diese

62
00:04:45,415 --> 00:04:50,450
Informationen aus dem anderen Dokument in das aktuelle Dokument zu füllen.

63
00:04:50,450 --> 00:04:54,370
Das ist, wo die Mongoose Bevölkerung zu unserer Rettung kommt.

64
00:04:54,370 --> 00:04:57,770
Um diese Idee weiter zu nehmen, lassen Sie mich Ihnen ein detailliertes

65
00:04:57,770 --> 00:05:02,600
Beispiel aus dem Kommentarschema zeigen, das wir zuvor definiert haben.

66
00:05:02,600 --> 00:05:06,850
So haben wir im CommentSchema bereits das Bewertungsfeld und

67
00:05:06,850 --> 00:05:10,080
das Kommentarfeld, das wir dort bereits angegeben haben.

68
00:05:10,080 --> 00:05:13,320
Früher hatten wir auch das Autorenfeld früher.

69
00:05:13,320 --> 00:05:18,133
Für das Autorenfeld früher, wir speichern den Autor

70
00:05:18,133 --> 00:05:23,270
als String und, Der Standardwert auch für den Autor.

71
00:05:23,270 --> 00:05:28,285
Jetzt beim Speichern des Autors als Typzeichenfolge, wenn wir nun

72
00:05:28,285 --> 00:05:34,200
den Autor in eine Art von Mongoose.Schema.Types.ObjectID verwandeln.

73
00:05:34,200 --> 00:05:39,350
Das bedeutet, dass das Autorenfeld jetzt eine ObjectID enthält,

74
00:05:39,350 --> 00:05:42,870
die ein Verweis auf ein Benutzerdokument ist.

75
00:05:42,870 --> 00:05:46,090
Wie stellen Sie sicher, dass dies auf ein Benutzerdokument verweist?

76
00:05:46,090 --> 00:05:51,500
Dies ist also, wo diese zusätzliche Eigenschaft namens ref, die angibt, dass

77
00:05:51,500 --> 00:05:56,160
das Schema des Dokuments, auf das Sie sich hier beziehen, von dem Typ, dem Benutzer, dem

78
00:05:56,160 --> 00:05:59,590
Schema und dem Modell, das wir bereits früher hinzugefügt haben, ist.

79
00:05:59,590 --> 00:06:05,144
In diesem Fall wird das Kommentarschema nun erweitert, um die Autoreninformationen zu speichern,

80
00:06:05,144 --> 00:06:08,706
aber die Autoreninformationen sind in Form einer ObjectID.

81
00:06:08,706 --> 00:06:15,480
Dies ist ein Verweis auf das Benutzerdokument, das bereits in unserer Datenbank gespeichert ist.

82
00:06:15,480 --> 00:06:17,750
Nun, wie hilft uns das?

83
00:06:17,750 --> 00:06:22,667
Dies ist, wo, wie ich sagte, Mongoose Bevölkerung kommt zu unserer Hilfe.

84
00:06:22,667 --> 00:06:25,120
Wie funktioniert die Mungo Bevölkerung?

85
00:06:25,120 --> 00:06:30,150
Bei der Mungo Population besteht die Art und Weise, wie Mongoose Population funktioniert,

86
00:06:30,150 --> 00:06:35,363
darin, dass bestimmte Pfade innerhalb eines aktuellen Dokuments automatisch ersetzt werden.

87
00:06:35,363 --> 00:06:40,850
Das hat Verweis auf ein anderes Dokument durch die Informationen aus diesem anderen Dokument.

88
00:06:40,850 --> 00:06:46,282
So haben Sie im Kommentarschema beispielsweise ein Autorenfeld, das

89
00:06:46,282 --> 00:06:53,070
sich auf die ObjectID des Benutzerdokuments bezieht, das sich bereits in Ihrer Datenbank befindet.

90
00:06:53,070 --> 00:06:58,963
Wenn Sie also Mongoose bitten, dieses Gericht zu füllen,

91
00:06:58,963 --> 00:07:03,820
werden die Informationen über den Autor im Kommentarfeld

92
00:07:03,820 --> 00:07:05,240
aus dem Benutzerdokument aufgefüllt.

93
00:07:05,240 --> 00:07:09,447
So werden die Informationen über den spezifischen Autor, auf den dort verwiesen wird,

94
00:07:09,447 --> 00:07:12,130
abgerufen und in Ihr Gericht Dokument hinzugefügt.

95
00:07:12,130 --> 00:07:16,820
Und das zusammengesetzte Dokument wird erstellt und dann an Sie zurückgeschickt.

96
00:07:16,820 --> 00:07:19,370
Wie stellen wir sicher, dass dies geschieht?

97
00:07:19,370 --> 00:07:25,020
Hier hilft uns dieser Querverweis mit der ObjectID, wie wir gesehen haben.

98
00:07:25,020 --> 00:07:30,890
Wie passiert die Bevölkerung tatsächlich im Code?

99
00:07:30,890 --> 00:07:33,350
Werfen Sie einen Blick darauf, wie wir bevölkern würden, zum

100
00:07:33,350 --> 00:07:38,090
Beispiel, das Geschirr Dokument, das wir gerade zuvor gesehen haben.

101
00:07:38,090 --> 00:07:43,650
Früher waren wir Gerichte zu tun.Finden Sie alle Gerichte in unserer Datenbank zu finden.

102
00:07:43,650 --> 00:07:48,645
Jetzt, wenn Sie das Dishes Dokument gefunden haben, dann können Sie sagen, füllen.

103
00:07:48,645 --> 00:07:52,647
Und geben Sie dann innerhalb des Auffüllens als Parameter

104
00:07:52,647 --> 00:07:56,130
das spezifische Feld an, das ausgefüllt werden muss.

105
00:07:56,130 --> 00:07:59,380
Also hier spezifizieren wir comments.author.

106
00:07:59,380 --> 00:08:02,270
Nun ist die Erwartung, dass das Feld comments.author

107
00:08:02,270 --> 00:08:06,550
tatsächlich eine OjectID ist, die auf das Benutzerdokument verweist.

108
00:08:06,550 --> 00:08:10,502
Und so haben wir bereits unser Kommentarschema eingerichtet.

109
00:08:10,502 --> 00:08:16,418
Also dieser Auffüllen Aufruf, den wir hier ausführen, wird dann gehen und

110
00:08:16,418 --> 00:08:24,937
holen aus der Datenbank jeden einzelnen Autorendatensatz oder den Datensatz des Benutzers.

111
00:08:24,937 --> 00:08:27,457
Und dann nehmen Sie dieses Benutzerdokument und

112
00:08:27,457 --> 00:08:33,505
füllt es in das Geschirr Dokument, um das zusammengesetzte Dokument von hier aus zu konstruieren.

113
00:08:33,505 --> 00:08:35,525
Und dann, natürlich,

114
00:08:35,525 --> 00:08:39,579
gibt es einige nachfolgende Behandlung von Daten, die Sie erhalten haben.

115
00:08:39,579 --> 00:08:44,640
Und dann kann die Antwort oder Rückgabe der Daten an den Client an dieser Stelle erfolgen.

116
00:08:44,640 --> 00:08:49,110
Aber natürlich, lassen Sie mich Sie warnen, dass diese Populationsoperation

117
00:08:49,110 --> 00:08:52,020
keine einfache Aufgabe für den Server ist.

118
00:08:52,020 --> 00:08:56,825
Weil jedes einzelne Gericht, müssen Sie jeden einzelnen Kommentar zu untersuchen.

119
00:08:56,825 --> 00:09:01,385
Dann müssen Sie für jeden Kommentar ihre ObjectID für

120
00:09:01,385 --> 00:09:02,034
den Benutzer herausfinden.

121
00:09:02,034 --> 00:09:04,580
Dann rufen Sie dieses Benutzerdokument ab und

122
00:09:04,580 --> 00:09:07,203
füllen es dann innerhalb des Dish-Dokuments.

123
00:09:07,203 --> 00:09:09,329
Und dann muss das für

124
00:09:09,329 --> 00:09:13,113
jeden einzelnen Kommentar wiederholt werden, der in diesem Dishes Dokument enthalten ist.

125
00:09:13,113 --> 00:09:18,437
Es bedeutet im Wesentlichen, dass es viel länger dauern wird,

126
00:09:18,437 --> 00:09:23,720
bis die Serverseite die Anfrage abschließt und die Informationen an die Clientseite zurücksendet.

127
00:09:23,720 --> 00:09:31,020
Also würde ich vorschlagen, dass Sie Populate sehr vernünftig verwenden sollten.

128
00:09:31,020 --> 00:09:35,410
Sie sollten es nur unter Umständen verwenden, in denen Sie diese Informationen wirklich benötigen.

129
00:09:36,590 --> 00:09:42,529
Wenn Sie zum Beispiel einfach das Menü für Ihr Restaurant erstellen.

130
00:09:42,529 --> 00:09:46,522
Wenn Sie nur das Menü für Ihr Restaurant erstellen,

131
00:09:46,522 --> 00:09:51,267
müssen Sie möglicherweise nicht wirklich die Informationen über den Autor jedes

132
00:09:51,267 --> 00:09:54,010
Kommentars in das Kommentardokument überhaupt eingeben.

133
00:09:54,010 --> 00:09:57,270
Denn wenn Sie gerade das Menü für Ihr Restaurant rendern,

134
00:09:57,270 --> 00:10:01,730
werden Sie nicht die Kommentare für dieses spezielle Gericht zeigen.

135
00:10:01,730 --> 00:10:06,457
Wenn der Benutzer jedoch ein bestimmtes Gericht untersucht und

136
00:10:06,457 --> 00:10:09,804
die Kommentare zu diesem Zeitpunkt sehen möchte,

137
00:10:09,804 --> 00:10:13,660
möchten Sie möglicherweise eine serverseitige Anfrage ausführen.

138
00:10:13,660 --> 00:10:19,383
Und dann holen Sie die Kommentarinformationen mit den anderen

139
00:10:19,383 --> 00:10:24,540
Autoreninformationen in und erhalten Sie diese für die Verwendung innerhalb unserer Kundenseite.

140
00:10:24,540 --> 00:10:30,240
Also wieder, füllen ist eine wunderbare Art, Dinge zu tun, wenn erforderlich,

141
00:10:30,240 --> 00:10:35,610
aber verwenden Sie es sehr gerichtlich, nur wenn Sie wirklich die Informationen benötigen. Die

142
00:10:35,610 --> 00:10:38,370
Flexibilität, die

143
00:10:38,370 --> 00:10:42,540
uns bevölkert, ist also die Tatsache, dass wir nicht bevölkern müssen, wenn wir es nicht müssen.

144
00:10:42,540 --> 00:10:46,990
Aber wir können die Informationen füllen, wenn wir diese Informationen wirklich brauchen.

145
00:10:48,030 --> 00:10:51,450
Mit diesem schnellen Verständnis der Mongoose Bevölkerung,

146
00:10:51,450 --> 00:10:57,280
lassen Sie uns zu der Übung gehen, wo wir das Schemas Gerichte ändern,

147
00:10:57,280 --> 00:10:59,840
das Kommentarschema innerhalb des Schemas Gerichte.

148
00:10:59,840 --> 00:11:04,730
Und dann verwenden Sie Mongoose Populate, um die Informationen innerhalb unserer Gerichte zu füllen,

149
00:11:04,730 --> 00:11:09,255
wenn wir die Gerichteninformationen auf die Serverseite zurückgeben.

150
00:11:09,255 --> 00:11:15,745
Dies bedeutet auch, dass, wenn ein Kommentar zu einem bestimmten Gericht hinzugefügt wird,

151
00:11:16,775 --> 00:11:22,210
der Autor der Informationen des Kommentars auf der Serverseite erfasst werden muss.

152
00:11:22,210 --> 00:11:26,079
Nun kommt es so vor, dass wir auf die Art und Weise, wie

153
00:11:26,079 --> 00:11:29,740
wir unsere Server entwickelt haben, bereits diese Informationen für uns zur Verfügung gestellt werden.

154
00:11:29,740 --> 00:11:34,870
Wenn wir den Benutzer authentifizieren, werden die Informationen des Benutzers bereits in jede

155
00:11:34,870 --> 00:11:37,580
Anfrage geladen, die von der Client-Seite eingeht.

156
00:11:37,580 --> 00:11:41,200
Und so verwenden sie diese Benutzerinformationen, die uns zur Verfügung stehen.

157
00:11:41,200 --> 00:11:46,170
Wenn wir also den Kommentar auf der Serverseite veröffentlichen, werden wir auch die

158
00:11:46,170 --> 00:11:52,370
ID des Benutzers erfassen und sie dann im Autorenfeld des Kommentarschemas speichern.

159
00:11:52,370 --> 00:11:55,430
Dies sollte automatisch auf der Serverseite erfolgen.

160
00:11:55,430 --> 00:12:00,740
Der Kunde darf das Autorenfeld nicht explizit ausfüllen.

161
00:12:00,740 --> 00:12:04,348
Aber die Serverseite sollte den Benutzer validieren und nur für

162
00:12:04,348 --> 00:12:10,020
Benutzer, die angemeldet sind, würden Sie ihnen erlauben, zunächst Kommentare zu posten.

163
00:12:10,020 --> 00:12:12,688
Und wenn sie Kommentare veröffentlichen,

164
00:12:12,688 --> 00:12:18,392
füllen Sie automatisch das Autorenfeld für dieses Kommentardokument aus,

165
00:12:18,392 --> 00:12:23,740
indem Sie das Autorenfeld durch die ObjectID des Benutzers ersetzen.

166
00:12:23,740 --> 00:12:25,920
Nun, in der Übung, werden Sie sehen, wie ich das tue.

167
00:12:25,920 --> 00:12:30,780
Also achten Sie auf diese spezifische Sache in der Übung. Damit

168
00:12:30,780 --> 00:12:33,245
schließen wir diesen Vortrag ab,

169
00:12:33,245 --> 00:12:38,109
lassen Sie uns mit der Übung fortfahren, um die Verwendung von Mungo Population zu untersuchen.

170
00:12:38,109 --> 00:12:44,079
( MUSIK)