1
00:00:03,680 --> 00:00:06,035
En la lección anterior,

2
00:00:06,035 --> 00:00:08,550
aprendimos sobre el controlador MongoDB.

3
00:00:08,550 --> 00:00:14,250
Esto permite a nuestra aplicación de nodo comunicarse con un servidor MongoDB,

4
00:00:14,250 --> 00:00:19,660
y también almacenar y recuperar documentos del servidor MongoDB.

5
00:00:19,660 --> 00:00:23,310
También vimos que el controlador MongoDB nos proporciona

6
00:00:23,310 --> 00:00:28,770
muchos métodos que nos permiten crear colecciones dentro de una base de datos,

7
00:00:28,770 --> 00:00:30,925
agregar documentos a las colecciones

8
00:00:30,925 --> 00:00:35,695
y luego realizar varias operaciones en los documentos dentro de una colección.

9
00:00:35,695 --> 00:00:41,060
Ahora, cuando los documentos se almacenan en la base de datos,

10
00:00:41,060 --> 00:00:46,330
el controlador MongoDB no impone estructura a los documentos.

11
00:00:46,330 --> 00:00:52,640
Si necesitamos tener una estructura específica para los documentos y hacer cumplir esa estructura,

12
00:00:52,640 --> 00:00:58,505
entonces necesitamos hacer uso del módulo de nodo Mangoose que nos permite definir

13
00:00:58,505 --> 00:01:05,015
un esquema y una estructura para nuestros documentos que se almacenan en nuestra base de datos MongoDB,

14
00:01:05,015 --> 00:01:08,275
y aplica estrictamente la estructura.

15
00:01:08,275 --> 00:01:16,035
Veamos más detalles en esta conferencia y los ejercicios que siguen a esta conferencia.

16
00:01:16,035 --> 00:01:18,540
Como ya hemos aprendido,

17
00:01:18,540 --> 00:01:25,035
MongoDB almacena datos en colecciones en una base de datos.

18
00:01:25,035 --> 00:01:28,695
Estas colecciones consisten en una colección de documentos.

19
00:01:28,695 --> 00:01:30,750
Los propios documentos almacenados en

20
00:01:30,750 --> 00:01:35,405
una base de datos MongoDB no tienen una estructura específica impuesta al documento.

21
00:01:35,405 --> 00:01:38,570
Cualquier documento se puede almacenar en cualquier colección.

22
00:01:38,570 --> 00:01:46,370
MongoDB confía en el desarrollador para hacer cumplir la estructura de los documentos,

23
00:01:46,370 --> 00:01:52,295
y le da la responsabilidad completa al desarrollador para asegurarse de que los documentos

24
00:01:52,295 --> 00:01:58,670
de la estructura correcta se agregan y mantienen en las diversas colecciones.

25
00:01:58,670 --> 00:02:01,960
Ahora, es muy fácil violar esto.

26
00:02:01,960 --> 00:02:06,260
Así, por ejemplo, aunque puede comenzar con la suposición de

27
00:02:06,260 --> 00:02:11,030
que una conexión particular tendrá documentos de cierta estructura,

28
00:02:11,030 --> 00:02:17,045
puede insertar fácilmente documentos que no necesariamente cumplan con la estructura.

29
00:02:17,045 --> 00:02:21,170
Si usted es muy particular que la estructura de los documentos en

30
00:02:21,170 --> 00:02:25,550
una colección siempre tiene una estructura especificada,

31
00:02:25,550 --> 00:02:28,550
y siempre tendrá el conjunto específico de campos,

32
00:02:28,550 --> 00:02:32,540
entonces el MongoDB en sí no impone que

33
00:02:32,540 --> 00:02:36,630
tampoco el controlador MongoDB nodo que hemos visto en la lección anterior.

34
00:02:36,630 --> 00:02:40,565
Aquí es donde necesitaremos una forma más formal de imponer

35
00:02:40,565 --> 00:02:46,385
estructura a los documentos que se almacenan en una colección en una base de datos MongoDB.

36
00:02:46,385 --> 00:02:52,390
Aquí es donde el módulo de nodo de mangosta viene a nuestra ayuda.

37
00:02:52,390 --> 00:02:56,405
El módulo de nodo de mangosta impone

38
00:02:56,405 --> 00:03:01,875
una estructura estandarizada para los documentos que se almacenan en una colección particular. Por

39
00:03:01,875 --> 00:03:07,175
lo tanto, es por eso que a menudo escuchamos a la gente referirse a esto como el ODM de la mangosta.

40
00:03:07,175 --> 00:03:10,950
El ODM en sí es interpretado por algunas personas para referirse al

41
00:03:10,950 --> 00:03:16,995
Modelo de Datos de Objetos o a veces referido como Object Document Mapping,

42
00:03:16,995 --> 00:03:22,125
o algunas personas se refieren a él como ORM o Object Relational Mapping.

43
00:03:22,125 --> 00:03:27,755
Ahora, cuando hablamos de relacional que se aplica mucho más a las bases de datos relacionales,

44
00:03:27,755 --> 00:03:33,380
pero luego con las bases de datos SQL necesitábamos explícitamente el objeto al

45
00:03:33,380 --> 00:03:41,850
mapeo relacional para colocarlo entre la base de datos y nuestra propia aplicación.

46
00:03:41,850 --> 00:03:45,245
Porque dentro de la aplicación estaríamos buscando

47
00:03:45,245 --> 00:03:50,245
objetos, pero su almacenamiento en una base de datos SQL estará en forma de registros,

48
00:03:50,245 --> 00:03:52,585
por lo que necesita una asignación explícita.

49
00:03:52,585 --> 00:03:54,870
Como vimos con la base de datos NoSQL,

50
00:03:54,870 --> 00:03:56,685
esto no era explícitamente requerido.

51
00:03:56,685 --> 00:04:03,710
Pero si necesita imponer estructura a sus documentos que se almacenan en una colección

52
00:04:03,710 --> 00:04:10,790
, entonces el uso de Mangosta para imponer esta estructura es muy, muy útil.

53
00:04:10,790 --> 00:04:13,880
La forma en que Mangosta va alrededor

54
00:04:13,880 --> 00:04:18,275
imponiendo estructura en los documentos es a través del uso de esquema.

55
00:04:18,275 --> 00:04:21,995
Esquema, define la estructura de sus documentos.

56
00:04:21,995 --> 00:04:24,800
Hablemos de eso con un poco más de detalle.

57
00:04:24,800 --> 00:04:27,580
Entonces, ¿qué es exactamente el esquema de mangosta

58
00:04:27,580 --> 00:04:29,700
y qué trae a la mesa?

59
00:04:29,700 --> 00:04:34,700
Esquema de mangosta, implica una estructura en

60
00:04:34,700 --> 00:04:39,735
los datos que se almacenan en un documento en su base de datos. Por

61
00:04:39,735 --> 00:04:42,770
lo tanto, define todos los campos de su documento,

62
00:04:42,770 --> 00:04:45,349
y también especifica los tipos de los campos,

63
00:04:45,349 --> 00:04:47,345
y también puede proporcionarnos

64
00:04:47,345 --> 00:04:51,965
características adicionales que pueden habilitar la validación en estos campos.

65
00:04:51,965 --> 00:04:59,425
Así, por ejemplo, los diversos tipos de esquema que se admiten en Mongoose incluyen: String,

66
00:04:59,425 --> 00:05:03,195
Number, Date, Buffer, Boolean,

67
00:05:03,195 --> 00:05:06,295
Mixed, Id. de objeto y Array.

68
00:05:06,295 --> 00:05:09,070
En particular, vamos a ver el número de cadena,

69
00:05:09,070 --> 00:05:14,405
y una fecha, y Boolean en el ejercicio que sigue.

70
00:05:14,405 --> 00:05:18,075
Vamos a ver algunos de los otros en ejercicios posteriores.

71
00:05:18,075 --> 00:05:22,125
En particular, observe el uso del tipo de esquema de matriz.

72
00:05:22,125 --> 00:05:25,570
Por lo tanto, un tipo de esquema de matriz le permitiría

73
00:05:25,570 --> 00:05:31,640
crear una matriz de sub-documentos dentro del documento.

74
00:05:31,640 --> 00:05:33,740
Hablaré de eso en poco tiempo.

75
00:05:33,740 --> 00:05:36,940
Una vez definido un esquema,

76
00:05:36,960 --> 00:05:42,160
el esquema se utiliza en Mangosta para crear una función de modelo,

77
00:05:42,160 --> 00:05:49,830
y eso es lo que permite definir la estructura de los documentos en la base de datos.

78
00:05:49,830 --> 00:05:53,225
Los esquemas en sí pueden tener anidamiento.

79
00:05:53,225 --> 00:05:58,490
Por lo tanto, lo que significa que puede tener un subdocumento que están encerrados dentro de un documento.

80
00:05:58,490 --> 00:06:01,519
Normalmente, los subdocumentos se

81
00:06:01,519 --> 00:06:04,890
acomodan mediante la especificación de un esquema adicional

82
00:06:04,890 --> 00:06:11,870
y, a continuación, la definición de uno de los campos del esquema para que esté fuera del tipo del otro esquema.

83
00:06:11,870 --> 00:06:15,215
O incluso puede ir con una matriz de

84
00:06:15,215 --> 00:06:20,000
otro tipo de esquema dentro de un segundo esquema que defina.

85
00:06:20,000 --> 00:06:24,930
Veamos un ejemplo para aclarar algunos de estos con más detalle.

86
00:06:24,930 --> 00:06:32,010
Este ejemplo será del ejercicio que usted hará justo después de esta conferencia.

87
00:06:32,010 --> 00:06:37,705
Antes de que pueda hablar de esquemas y modelos en Mongoose,

88
00:06:37,705 --> 00:06:41,310
comprendamos por qué necesitaríamos eso.

89
00:06:41,310 --> 00:06:43,975
Si ha tomado el

90
00:06:43,975 --> 00:06:46,760
curso anterior angular, o el iónico, o el guión nativo,

91
00:06:46,760 --> 00:06:49,445
ha visto que representamos

92
00:06:49,445 --> 00:06:55,565
varios datos que utilizamos en nuestras aplicaciones en forma de cadenas JSON.

93
00:06:55,565 --> 00:07:02,050
Por lo tanto, en nuestra aplicación definimos una colección llamada como platos.

94
00:07:02,050 --> 00:07:03,770
En una colección de platos,

95
00:07:03,770 --> 00:07:09,700
cada plato contendrá un cierto conjunto de propiedades definidas en forma de cadena JSON,

96
00:07:09,700 --> 00:07:11,665
como se ve en este ejemplo aquí.

97
00:07:11,665 --> 00:07:15,830
Por lo tanto, los platos son una variedad de tipo de

98
00:07:15,830 --> 00:07:18,605
plato, y cada plato en sí contendrá

99
00:07:18,605 --> 00:07:20,290
un nombre, una imagen,

100
00:07:20,290 --> 00:07:22,015
una categoría, una etiqueta, etc.

101
00:07:22,015 --> 00:07:26,360
Además, dentro del documento de plato en sí,

102
00:07:26,360 --> 00:07:32,830
tendría comentarios que se almacenan como una matriz de nuevo, -

103
00:07:32,830 --> 00:07:38,240
documentos JSON que contienen campos específicos paso. Por

104
00:07:38,240 --> 00:07:39,750
lo tanto, cada comentario, por ejemplo,

105
00:07:39,750 --> 00:07:45,685
contiene un autor de comentario de calificación y un campo de fecha como se ve en este ejemplo aquí.

106
00:07:45,685 --> 00:07:49,215
Por lo tanto, usted ve que hay una estructura clara en

107
00:07:49,215 --> 00:07:55,230
cada documento que define un plato que se almacena en nuestra base de datos.

108
00:07:55,230 --> 00:08:02,545
Múltiples platos, obviamente, se almacenarán en forma de colección en nuestra base de datos,

109
00:08:02,545 --> 00:08:06,655
y podrían ser agrupados y enviados como una variedad de

110
00:08:06,655 --> 00:08:11,165
platos a nuestra aplicación cliente para ser utilizados.

111
00:08:11,165 --> 00:08:14,890
Ahora que hemos entendido cómo se define esto, ahora,

112
00:08:14,890 --> 00:08:22,000
¿cómo se relaciona esto con el esquema de Mangosta y el modelo que definimos en Mangosta?

113
00:08:22,000 --> 00:08:27,460
Ahora, tenga en cuenta la estructura de un documento de plato típico aquí.

114
00:08:27,460 --> 00:08:34,095
Por lo tanto, esto podría ser fácilmente mapeado en un documento MongoDB en una colección,

115
00:08:34,095 --> 00:08:37,375
tal vez llamado la colección de platos.

116
00:08:37,375 --> 00:08:42,605
Por lo tanto, vemos que hay una estructura clara en el documento mismo.

117
00:08:42,605 --> 00:08:50,320
Ahora, ¿cómo reflejamos esto en un esquema en nuestra aplicación Mangoose?

118
00:08:50,320 --> 00:08:54,095
Como aprenderás en el ejercicio,

119
00:08:54,095 --> 00:08:57,900
veremos que definiríamos esquemas en Mangosta.

120
00:08:57,900 --> 00:09:03,085
Entonces, el esquema se define como un esquema de mangosta aquí.

121
00:09:03,085 --> 00:09:08,055
A modo de ejemplo, aquí se muestra un CommentSchema.

122
00:09:08,055 --> 00:09:09,925
El CommentSchema, como puede ver,

123
00:09:09,925 --> 00:09:13,885
contiene tres campos diferentes: la calificación, el comentario

124
00:09:13,885 --> 00:09:15,445
y el campo autor,

125
00:09:15,445 --> 00:09:18,745
y también marcas de hora aquí.

126
00:09:18,745 --> 00:09:23,560
Las marcas de tiempo le permiten tener dos campos diferentes en

127
00:09:23,560 --> 00:09:28,850
el documento: el campo creado en y el campo actualizado en,

128
00:09:28,850 --> 00:09:38,200
ambos de los cuales son marcas de tiempo almacenadas en forma de cadena de fecha ISO en el documento.

129
00:09:38,200 --> 00:09:43,615
Ahora, la calificación en sí sería un valor entero.

130
00:09:43,615 --> 00:09:46,400
Por lo tanto, en la terminología de Mangosta,

131
00:09:46,400 --> 00:09:48,755
se almacenará como un número,

132
00:09:48,755 --> 00:09:50,680
el tipo sería un número.

133
00:09:50,680 --> 00:09:53,660
Incluso puede especificar el valor mínimo y el máximo.

134
00:09:53,660 --> 00:09:57,190
También puede especificar que este campo en particular es obligatorio, lo

135
00:09:57,190 --> 00:10:04,460
que significa que cada documento del tipo de comentario debe contener un campo de calificación.

136
00:10:04,460 --> 00:10:07,370
Del mismo modo, también puede definir un campo de comentario,

137
00:10:07,370 --> 00:10:08,710
que es de la cadena de tipo.

138
00:10:08,710 --> 00:10:13,635
Por lo tanto, obviamente, un comentario no es más que una cadena que contiene cierta información,

139
00:10:13,635 --> 00:10:16,340
y esto también se puede definir como un campo obligatorio,

140
00:10:16,340 --> 00:10:18,805
lo que significa que cada documento debe contener un comentario,

141
00:10:18,805 --> 00:10:21,060
y también un campo de autor,

142
00:10:21,060 --> 00:10:22,800
que también es de la cadena de tipo.

143
00:10:22,800 --> 00:10:28,030
Por lo tanto, se ve que definiendo este esquema en este formato.

144
00:10:28,030 --> 00:10:32,600
Como aprendimos en la discusión un poco antes,

145
00:10:32,600 --> 00:10:41,890
esquema se define mediante el uso de los diversos tipos que tenemos en nuestra aplicación Mangoose.

146
00:10:41,890 --> 00:10:43,030
Por lo tanto, en el esquema, de nuevo,

147
00:10:43,030 --> 00:10:44,900
se ven tres campos diferentes aquí,

148
00:10:44,900 --> 00:10:47,135
calificación, comentario y autor aquí,

149
00:10:47,135 --> 00:10:50,665
y cada uno de los cuales tiene un tipo específico dado,

150
00:10:50,665 --> 00:10:53,060
y luego si esto es obligatorio o no. Por

151
00:10:53,060 --> 00:10:56,505
lo tanto, está imponiendo una estructura estricta

152
00:10:56,505 --> 00:11:01,320
en los documentos de comentarios que se almacenarán en su aplicación.

153
00:11:01,320 --> 00:11:05,255
Ahora que hemos definido un esquema de comentarios, podemos entonces,

154
00:11:05,255 --> 00:11:12,254
como notó en el ejemplo del tipo de datos que necesitamos en nuestra aplicación,

155
00:11:12,254 --> 00:11:15,000
tenemos un documento de plato en sí.

156
00:11:15,000 --> 00:11:17,620
El documento del plato contiene varios campos.

157
00:11:17,620 --> 00:11:19,050
Aquí, en el ejercicio,

158
00:11:19,050 --> 00:11:23,355
primero introduciremos solo dos campos en el documento del plato,

159
00:11:23,355 --> 00:11:25,370
el nombre y la descripción.

160
00:11:25,370 --> 00:11:27,010
En la siguiente lección,

161
00:11:27,010 --> 00:11:32,330
vamos a introducir los campos restantes para el DishSchema.

162
00:11:32,330 --> 00:11:33,680
Ahora, entonces el nombre,

163
00:11:33,680 --> 00:11:35,440
como en este caso,

164
00:11:35,440 --> 00:11:36,765
es del tipo string.

165
00:11:36,765 --> 00:11:39,450
También podemos especificar que se trata de un campo obligatorio,

166
00:11:39,450 --> 00:11:43,360
lo que significa que cada documento debe contener el campo de nombre.

167
00:11:43,360 --> 00:11:46,385
También podemos especificar que el campo de nombre es único,

168
00:11:46,385 --> 00:11:53,215
lo que significa que no hay dos documentos que tengan exactamente el mismo valor de nombre en el documento.

169
00:11:53,215 --> 00:11:55,980
Por lo tanto, eso asegura que cada documento tendrá

170
00:11:55,980 --> 00:12:01,300
un campo de nombre único en él y un campo de descripción,

171
00:12:01,300 --> 00:12:03,115
que es de nuevo de la cadena de tipo,

172
00:12:03,115 --> 00:12:06,460
pero también especificado según sea necesario.

173
00:12:06,460 --> 00:12:10,010
Ahora, como vimos en el ejemplo,

174
00:12:10,010 --> 00:12:15,750
un documento de plato contiene varios comentarios encerrados dentro del documento.

175
00:12:15,750 --> 00:12:20,920
Ahora, en Mangosta, esto es apoyado por el uso de sub-documentos. Por

176
00:12:20,920 --> 00:12:24,230
lo tanto, si define un esquema anteriormente,

177
00:12:24,230 --> 00:12:27,345
por ejemplo, ya hemos definido aquí un CommentSchema,

178
00:12:27,345 --> 00:12:33,370
también puede definir un campo en otro esquema que defina y, a

179
00:12:33,370 --> 00:12:36,240
continuación, especificar que ese campo será

180
00:12:36,240 --> 00:12:39,520
del tipo del esquema anterior que haya definido.

181
00:12:39,520 --> 00:12:40,960
Entonces, en este caso,

182
00:12:40,960 --> 00:12:44,360
el campo de comentarios, lo estoy definiendo como una matriz,

183
00:12:44,360 --> 00:12:51,545
por lo que ve el uso de un tipo de matriz en su esquema que está definiendo aquí,

184
00:12:51,545 --> 00:12:55,110
y luego matriz del tipo CommentSchema.

185
00:12:55,110 --> 00:13:00,725
Por lo tanto, esta es una serie de comentarios que se incluirán en cada documento de plato. Por

186
00:13:00,725 --> 00:13:02,590
lo tanto, puede tener

187
00:13:02,590 --> 00:13:11,640
más de un subdocumento de comentario adjunto dentro de un documento de plato.

188
00:13:11,640 --> 00:13:16,080
Por lo tanto, definir la estructura como esta nos permite apoyar

189
00:13:16,080 --> 00:13:20,950
la estructura de cadena JSON correspondiente que hemos definido

190
00:13:20,950 --> 00:13:26,470
para un documento de plato o que hemos visto en el ejemplo anterior.

191
00:13:26,470 --> 00:13:30,145
Ahora, una vez que definamos el esquema,

192
00:13:30,145 --> 00:13:33,695
para hacer uso de esto en nuestra aplicación,

193
00:13:33,695 --> 00:13:38,600
necesitamos crear un modelo a partir de ese esquema que acabamos de definir.

194
00:13:38,600 --> 00:13:40,640
Por lo tanto, dentro de nuestra aplicación,

195
00:13:40,640 --> 00:13:45,320
vamos a definir un modelo de mangosta y especificar que el modelo

196
00:13:45,320 --> 00:13:51,085
está fuera del tipo dishSchema en este ejemplo.

197
00:13:51,085 --> 00:13:54,830
No solo eso, también le dará un nombre al modelo aquí.

198
00:13:54,830 --> 00:13:57,100
Por lo tanto, cuando le das un nombre al modelo aquí,

199
00:13:57,100 --> 00:14:00,000
estamos especificando el nombre como plato.

200
00:14:00,000 --> 00:14:03,860
Ahora, cuando use este modelo de plato en

201
00:14:03,860 --> 00:14:07,870
nuestra aplicación de nodo donde estamos haciendo uso de Mangoose,

202
00:14:07,870 --> 00:14:15,280
entonces esto se transformará y mapeará en una colección en mi base de datos MongoDB.

203
00:14:15,280 --> 00:14:18,885
La colección en sí será nombrada como platos.

204
00:14:18,885 --> 00:14:23,355
Por lo tanto, Mongoose sabe automáticamente que cuando especifica un nombre aquí,

205
00:14:23,355 --> 00:14:27,990
construirá automáticamente el plural

206
00:14:27,990 --> 00:14:31,635
de ese nombre y luego le dará a la colección el nombre,

207
00:14:31,635 --> 00:14:37,160
que es el plural del nombre del modelo que especifique en este ejemplo aquí.

208
00:14:37,160 --> 00:14:39,400
Entonces, cuando digo plato aquí,

209
00:14:39,400 --> 00:14:42,620
entonces Mongoose automáticamente asignará esto a la

210
00:14:42,620 --> 00:14:46,365
colección de platos en la base de datos de MongoDB.

211
00:14:46,365 --> 00:14:53,385
¿ Cómo sabe convertir este nombre singular en plural?

212
00:14:53,385 --> 00:14:56,750
Mangoose tiene automáticamente un mecanismo incorporado que

213
00:14:56,750 --> 00:15:01,795
le permite construir los plurales de palabras estándar en inglés.

214
00:15:01,795 --> 00:15:02,965
Entonces, si dices plato,

215
00:15:02,965 --> 00:15:04,170
construirá platos.

216
00:15:04,170 --> 00:15:08,880
Si dices líder, construirá el plural de él como líderes, y así sucesivamente.

217
00:15:08,880 --> 00:15:13,250
Por lo tanto, esto ya está integrado en el módulo de nodo de mangosta.

218
00:15:13,250 --> 00:15:17,585
Entonces, es por eso que cuando especifico esto como un tipo de modelo de plato,

219
00:15:17,585 --> 00:15:24,050
entonces Mangoose construirá la colección de platos en mi base de datos MongoDB,

220
00:15:24,050 --> 00:15:27,155
y luego esa colección de platos almacenará

221
00:15:27,155 --> 00:15:33,050
los diversos documentos del tipo de plato allí.

222
00:15:33,050 --> 00:15:35,780
Una vez que hemos creado eso, normalmente,

223
00:15:35,780 --> 00:15:38,150
cuando declaramos modelos en nuestra aplicación,

224
00:15:38,150 --> 00:15:43,780
los almacenaríamos en una subcarpeta llamada modelos, sólo por conveniencia.

225
00:15:43,780 --> 00:15:44,900
No es necesario hacer eso,

226
00:15:44,900 --> 00:15:47,320
pero solo para organizar su aplicación,

227
00:15:47,320 --> 00:15:50,635
normalmente lo almacenaríamos en una carpeta llamada modelos.

228
00:15:50,635 --> 00:15:55,010
Entonces el esquema y el modelo se

229
00:15:55,010 --> 00:15:59,470
definirían en un archivo como este como se ve en el ejemplo aquí,

230
00:15:59,470 --> 00:16:05,230
esto llamado dishes.js, y luego esto se exportaría porque se trata de un módulo de nodo.

231
00:16:05,230 --> 00:16:10,970
Esto se exportará desde este archivo para que pueda ser incluido en la aplicación de nodo,

232
00:16:10,970 --> 00:16:13,100
donde vamos a hacer uso de

233
00:16:13,100 --> 00:16:16,620
este esquema y del modelo que acabamos de definir aquí.

234
00:16:16,620 --> 00:16:20,540
Con esta rápida comprensión del esquema y el modelo y

235
00:16:20,540 --> 00:16:26,370
su uso en la definición de la estructura de un documento que almacenamos en un MongoDB,

236
00:16:26,370 --> 00:16:33,510
vamos a volver atrás y entender un poco más acerca de lo que Mangoose proporciona para nosotros.

237
00:16:33,510 --> 00:16:39,965
Además, Mangoose nos permite establecer la conexión con el servidor MongoDB.

238
00:16:39,965 --> 00:16:43,070
Mangosta hace uso internamente

239
00:16:43,070 --> 00:16:46,495
del controlador MongoDB que habíamos utilizado en el ejercicio anterior.

240
00:16:46,495 --> 00:16:49,745
Por lo tanto, Mangoose depende del controlador MongoDB, por lo

241
00:16:49,745 --> 00:16:53,824
que, lo que significa que desde su aplicación de nodo basada en Mongoose,

242
00:16:53,824 --> 00:16:56,960
puede usar todos los métodos que ya están

243
00:16:56,960 --> 00:17:01,040
disponibles desde el controlador MongoDB también si lo desea,

244
00:17:01,040 --> 00:17:05,390
pero Mangoose tiene su propia colección de métodos que

245
00:17:05,390 --> 00:17:09,940
podemos hacer de para interactuar con la base de datos MongoDB,

246
00:17:09,940 --> 00:17:13,645
como veremos en el ejercicio que sigue.

247
00:17:13,645 --> 00:17:19,040
Permítanme mostrarles brevemente cómo estableceríamos una conexión con la base de datos,

248
00:17:19,040 --> 00:17:21,590
y lo harán en el ejercicio que sigue.

249
00:17:21,590 --> 00:17:25,280
Por lo tanto, al igual que declaramos la URL en

250
00:17:25,280 --> 00:17:29,160
el caso de la aplicación del nodo MongoDB en la lección anterior,

251
00:17:29,160 --> 00:17:32,630
todavía declararemos la URL de nuestra aplicación.

252
00:17:32,630 --> 00:17:36,965
Luego usaremos el método de conexión de mangosta

253
00:17:36,965 --> 00:17:40,180
y proporcionaremos la URL para el método de conexión de mangosta,

254
00:17:40,180 --> 00:17:44,000
y esto establecerá la conexión a la base de datos.

255
00:17:44,000 --> 00:17:48,590
Con esta rápida comprensión de Mangosta y el papel que

256
00:17:48,590 --> 00:17:53,485
juega Mangoose en el apoyo a la inserción estructurada

257
00:17:53,485 --> 00:17:58,985
, el almacenamiento y la recuperación de documentos de nuestro MongoDB,

258
00:17:58,985 --> 00:18:02,180
pasemos al ejercicio donde

259
00:18:02,180 --> 00:18:07,920
obtendremos alguna experiencia práctica usando el módulo Mangoose.