1
00:00:01,180 --> 00:00:02,990
‫Narrador: Uno de los pasos

2
00:00:02,990 --> 00:00:06,250
‫más importantes en la creación de aplicaciones intensivas en datos

3
00:00:06,250 --> 00:00:08,700
‫es modelar realmente todos estos datos en MongoDB.

4
00:00:08,700 --> 00:00:12,300
‫Y de eso es de lo que vamos a hablar en esta conferencia.

5
00:00:12,300 --> 00:00:14,710
‫Por lo tanto, es realmente crucial que

6
00:00:14,710 --> 00:00:19,710
‫lo sigas, incluso al principio, es mucho para asimilar. Está bien.

7
00:00:19,810 --> 00:00:22,013
‫De todos modos, comencemos ahora.

8
00:00:23,530 --> 00:00:27,530
‫Ahora, el modelado de datos probablemente sea un concepto muy nuevo para usted.

9
00:00:27,530 --> 00:00:28,920
‫Así que antes

10
00:00:28,920 --> 00:00:32,070
‫de empezar; Dejemos en claro de qué vamos a hablar.

11
00:00:32,070 --> 00:00:35,656
‫Entonces, el modelado de datos es el proceso de tomar datos

12
00:00:35,656 --> 00:00:38,770
‫no estructurados generados por un escenario del mundo real y

13
00:00:38,770 --> 00:00:42,090
‫luego estructurarlos en un modelo de datos lógicos en una

14
00:00:42,090 --> 00:00:43,410
‫base de datos.

15
00:00:43,410 --> 00:00:46,300
‫Y lo hacemos de acuerdo con un

16
00:00:46,300 --> 00:00:49,330
‫conjunto de criterios que aprenderemos en este video.

17
00:00:49,330 --> 00:00:51,980
‫Por ejemplo; digamos que queremos diseñar un modelo

18
00:00:51,980 --> 00:00:54,120
‫de datos de tienda online.

19
00:00:54,120 --> 00:00:57,040
‫Inicialmente habrá una tonelada de datos no estructurados que

20
00:00:57,040 --> 00:00:58,130
‫sabemos que necesitamos.

21
00:00:58,130 --> 00:00:58,980
‫Derecha.

22
00:00:58,980 --> 00:01:00,900
‫Cosas como productos, categorías,

23
00:01:00,900 --> 00:01:03,875
‫pedidos de clientes, carritos de compras, proveedores.

24
00:01:03,875 --> 00:01:06,300
‫Y así sucesivamente y así sucesivamente.

25
00:01:06,300 --> 00:01:09,240
‫Nuestro objetivo con el modelado de datos es luego estructurar

26
00:01:09,240 --> 00:01:11,450
‫estos datos de una manera lógica.

27
00:01:11,450 --> 00:01:14,090
‫Reflejando las relaciones del mundo real que

28
00:01:14,090 --> 00:01:16,920
‫existen entre algunos de estos conjuntos de datos.

29
00:01:16,920 --> 00:01:19,670
‫Un poco como puedes ver en este ejemplo.

30
00:01:19,670 --> 00:01:23,110
‫Y esto, por supuesto, es solo una especie de situación imaginaria, pero

31
00:01:23,110 --> 00:01:24,320
‫entiendes la idea.

32
00:01:24,320 --> 00:01:25,600
‫Derecha.

33
00:01:25,600 --> 00:01:28,940
‫Ahora, muchos desarrolladores de backend dicen que el modelado de datos

34
00:01:28,940 --> 00:01:30,930
‫es donde más tenemos que pensar.

35
00:01:30,930 --> 00:01:33,670
‫Esa es la parte más exigente de la construcción

36
00:01:33,670 --> 00:01:35,310
‫de una aplicación completa.

37
00:01:35,310 --> 00:01:38,100
‫Porque realmente no siempre es sencillo.

38
00:01:38,100 --> 00:01:41,070
‫Y a veces simplemente no hay respuestas correctas.

39
00:01:41,070 --> 00:01:45,500
‫Así que no es solo una forma única y correcta de estructurar los datos.

40
00:01:45,500 --> 00:01:48,420
‫Pero de todos modos haré todo lo posible para establecer el

41
00:01:48,420 --> 00:01:49,510
‫proceso en este video.

42
00:01:49,510 --> 00:01:52,367
‫Y para eso vamos a seguir cuatro pasos.

43
00:01:52,367 --> 00:01:56,200
‫Así que en el primer paso; aprendimos cómo identificar

44
00:01:56,200 --> 00:01:59,340
‫diferentes tipos de relaciones entre datos.

45
00:01:59,340 --> 00:02:00,360
‫Entonces

46
00:02:00,360 --> 00:02:03,019
‫entenderemos la diferencia entre

47
00:02:03,019 --> 00:02:07,163
‫referenciar o normalización e incrustación o desnormalización.

48
00:02:07,163 --> 00:02:09,030
‫En el siguiente y

49
00:02:09,030 --> 00:02:11,660
‫más importante paso; Le mostraré mi marco para

50
00:02:11,660 --> 00:02:13,560
‫decidir si debemos incrustar documentos

51
00:02:13,560 --> 00:02:15,750
‫o hacer referencia a otros documentos

52
00:02:15,750 --> 00:02:18,690
‫en función de un par de factores diferentes.

53
00:02:18,690 --> 00:02:20,810
‫Además, tenemos que hablar rápidamente sobre

54
00:02:20,810 --> 00:02:22,680
‫diferentes tipos de referencias.

55
00:02:22,680 --> 00:02:25,920
‫Porque eso es importante si ese es el tipo de

56
00:02:25,920 --> 00:02:28,220
‫diseño que elegimos para nuestros datos.

57
00:02:28,220 --> 00:02:32,290
‫Así que, de hecho, esta será una conferencia bastante teórica.

58
00:02:32,290 --> 00:02:35,940
‫Pero también uno absolutamente esencial para su progreso

59
00:02:35,940 --> 00:02:37,660
‫como desarrollador back-end.

60
00:02:37,660 --> 00:02:41,553
‫Porque la forma en que diseñamos los datos y la forma en

61
00:02:41,553 --> 00:02:45,180
‫que modelamos nuestros datos puede hacer o deshacer toda nuestra aplicación.

62
00:02:45,180 --> 00:02:47,950
‫Y habrá muchos ejemplos a lo largo del camino

63
00:02:47,950 --> 00:02:49,510
‫para facilitar este proceso.

64
00:02:49,510 --> 00:02:50,343
‫Está bien.

65
00:02:51,320 --> 00:02:53,440
‫Y lo primero de lo que

66
00:02:53,440 --> 00:02:55,780
‫vamos a hablar es de los diferentes tipos

67
00:02:55,780 --> 00:02:58,210
‫de relaciones que pueden existir entre los datos.

68
00:02:58,210 --> 00:03:00,780
‫Entonces hay tres grandes tipos de relaciones.

69
00:03:00,780 --> 00:03:05,150
‫Uno a uno, uno a muchos y muchos a muchos.

70
00:03:05,150 --> 00:03:06,990
‫Y voy a usar una aplicación

71
00:03:06,990 --> 00:03:08,890
‫de película como ejemplo en esta diapositiva.

72
00:03:08,890 --> 00:03:10,000
‫¿Okey?

73
00:03:10,000 --> 00:03:12,440
‫Entonces, primero, una relación uno a

74
00:03:12,440 --> 00:03:14,140
‫uno entre datos es

75
00:03:14,140 --> 00:03:17,370
‫básicamente cuando un campo solo puede tener un valor.

76
00:03:17,370 --> 00:03:21,550
‫Entonces, en nuestro ejemplo de aplicación de película; una película solo

77
00:03:21,550 --> 00:03:22,990
‫tiene un nombre.

78
00:03:22,990 --> 00:03:24,910
‫Y este es un ejemplo

79
00:03:24,910 --> 00:03:27,160
‫simple de una relación uno a uno.

80
00:03:27,160 --> 00:03:29,690
‫Pero estas relaciones no son realmente tan importantes en

81
00:03:29,690 --> 00:03:31,363
‫términos de modelado de datos.

82
00:03:32,330 --> 00:03:34,430
‫Ahora, las relaciones más

83
00:03:34,430 --> 00:03:37,210
‫importantes son las de muchas relaciones.

84
00:03:37,210 --> 00:03:39,770
‫Y son tan importantes que en

85
00:03:39,770 --> 00:03:42,510
‫MongoDB distinguimos entre tres tipos de relaciones

86
00:03:42,510 --> 00:03:44,540
‫de uno a muchos.

87
00:03:44,540 --> 00:03:49,540
‫Uno para unos pocos, uno para muchos, y uno para una tonelada o un

88
00:03:49,910 --> 00:03:53,230
‫millón o algo así. Entonces, la diferencia aquí se

89
00:03:53,230 --> 00:03:56,893
‫basa en la cantidad relativa de muchos. Está bien.

90
00:03:57,840 --> 00:04:00,969
‫Entonces, un ejemplo de una relación de uno a

91
00:04:00,969 --> 00:04:05,967
‫unos pocos es que una película puede ganar muchos premios, pero en realidad solo unos pocos.

92
00:04:05,967 --> 00:04:09,630
‫Así que la película no va a ganar mil premios,

93
00:04:09,630 --> 00:04:11,220
‫pero puede ganar algunos.

94
00:04:11,220 --> 00:04:14,930
‫Y esta es una relación típica de uno a pocos.

95
00:04:14,930 --> 00:04:18,710
‫Entonces, verá que, en general, una relación de uno

96
00:04:18,710 --> 00:04:23,210
‫a muchos significa que un documento puede relacionarse con muchos otros documentos.

97
00:04:23,210 --> 00:04:26,680
‫Ahora, esto puede parecer un poco abstracto sin los datos JSON, pero ese

98
00:04:26,680 --> 00:04:28,480
‫es en realidad el propósito aquí.

99
00:04:28,480 --> 00:04:31,040
‫Solo quiero mostrarles una descripción general

100
00:04:31,040 --> 00:04:33,759
‫conceptual de estos diferentes tipos de relaciones.

101
00:04:33,759 --> 00:04:36,872
‫De todos modos, cualquier relación de uno a

102
00:04:36,872 --> 00:04:40,600
‫muchos, un documento puede relacionarse con cientos o miles

103
00:04:40,600 --> 00:04:42,070
‫de otros documentos.

104
00:04:42,070 --> 00:04:44,788
‫Por ejemplo; una película puede tener miles de

105
00:04:44,788 --> 00:04:46,710
‫reseñas en nuestra aplicación.

106
00:04:46,710 --> 00:04:49,380
‫Y entonces esta no es realmente una relación de uno a pocos, sino

107
00:04:49,380 --> 00:04:51,524
‫de uno a muchos. ¿Okey?

108
00:04:51,524 --> 00:04:55,616
‫Y finalmente tenemos la relación one to ton.

109
00:04:55,616 --> 00:04:59,720
‫Imagínese que quisiéramos implementar alguna funcionalidad de registro

110
00:04:59,720 --> 00:05:03,110
‫en nuestra aplicación. Básicamente, para saber exactamente

111
00:05:03,110 --> 00:05:04,870
‫qué está pasando en nuestro servidor.

112
00:05:04,870 --> 00:05:08,770
‫Estos registros pueden crecer fácilmente a millones de documentos.

113
00:05:08,770 --> 00:05:11,270
‫Y este es un ejemplo muy

114
00:05:11,270 --> 00:05:14,200
‫típico de una relación de uno a toneladas.

115
00:05:14,200 --> 00:05:17,100
‫Y la diferencia entre muchos y una tonelada es,

116
00:05:17,100 --> 00:05:20,730
‫por supuesto, un poco confusa, pero piense que si algo puede

117
00:05:20,730 --> 00:05:23,360
‫crecer casi hasta el infinito, definitivamente es una

118
00:05:23,360 --> 00:05:25,532
‫relación de uno a una tonelada.

119
00:05:25,532 --> 00:05:28,763
‫Así que, de nuevo, las relaciones de uno a

120
00:05:28,763 --> 00:05:31,650
‫muchos son las más importantes que debe conocer.

121
00:05:31,650 --> 00:05:34,050
‫Por cierto; en las bases

122
00:05:34,050 --> 00:05:37,061
‫de datos relacionales hay solo uno a

123
00:05:37,061 --> 00:05:39,800
‫muchos sin cuantificar cuánto es realmente.

124
00:05:39,800 --> 00:05:41,800
‫En las bases de datos de

125
00:05:41,800 --> 00:05:44,010
‫MongoDB, sin embargo, es una diferencia extremadamente importante.

126
00:05:44,010 --> 00:05:47,150
‫Porque es uno de los factores que usaremos

127
00:05:47,150 --> 00:05:49,891
‫para decidir si debemos desnormalizar o

128
00:05:49,891 --> 00:05:53,340
‫normalizar los datos, como aprenderá un poco más adelante.

129
00:05:53,340 --> 00:05:57,181
‫De todos modos, el tipo de relación menor es el de muchos

130
00:05:57,181 --> 00:06:00,149
‫a muchos donde una película puede tener muchos actores.

131
00:06:00,149 --> 00:06:04,876
‫Pero al mismo tiempo, un actor puede actuar en muchas películas.

132
00:06:04,876 --> 00:06:07,910
‫Y aquí la relación básicamente va

133
00:06:07,910 --> 00:06:09,630
‫en ambas direcciones.

134
00:06:09,630 --> 00:06:11,800
‫Donde antes en los otros tipos

135
00:06:11,800 --> 00:06:13,939
‫era solo en una dirección.

136
00:06:13,939 --> 00:06:17,470
‫Por ejemplo, una película puede tener muchas reseñas, pero una

137
00:06:17,470 --> 00:06:22,450
‫específica es solo para esa película. Derecha.

138
00:06:22,450 --> 00:06:24,560
‫Y lo mismo ocurre con los premios.

139
00:06:24,560 --> 00:06:27,506
‫Entonces, un premio específico como el mejor

140
00:06:27,506 --> 00:06:30,914
‫actor es para una sola película, no para varias.

141
00:06:30,914 --> 00:06:35,580
‫Pero con las películas y los actores es realmente diferente.

142
00:06:35,580 --> 00:06:39,250
‫Una vez más, una película está protagonizada por muchos actores, pero

143
00:06:39,250 --> 00:06:41,920
‫un actor interpreta muchas películas, por

144
00:06:41,920 --> 00:06:45,020
‫lo que es una relación de muchos a muchos.

145
00:06:45,020 --> 00:06:46,170
‫Bueno.

146
00:06:46,170 --> 00:06:49,060
‫Así que tenga todo esto en cuenta a medida que avanzamos

147
00:06:49,060 --> 00:06:50,063
‫en esta conferencia.

148
00:06:51,760 --> 00:06:54,870
‫Y probablemente el aspecto más importante que necesitamos aprender sobre

149
00:06:54,870 --> 00:06:57,900
‫las bases de datos de MongoDB es hacer referencia

150
00:06:57,900 --> 00:07:00,340
‫e incrustar dos conjuntos de datos.

151
00:07:00,340 --> 00:07:02,350
‫Y en realidad ya hablamos

152
00:07:02,350 --> 00:07:05,050
‫un poco sobre esto antes, pero revisémoslo aquí

153
00:07:05,050 --> 00:07:07,311
‫y profundicemos un poco más también.

154
00:07:07,311 --> 00:07:09,962
‫Entonces, cada vez que tengamos dos

155
00:07:09,962 --> 00:07:13,829
‫conjuntos de datos relacionados, podemos representar esos datos relacionados en

156
00:07:13,829 --> 00:07:18,829
‫una forma de referencia o normalizada o en una forma incrustada o desnormalizada.

157
00:07:18,842 --> 00:07:22,190
‫Y sigo usando los dos términos relacionados juntos, como hacer

158
00:07:22,190 --> 00:07:24,340
‫referencia y normalizar, porque verá que

159
00:07:24,340 --> 00:07:26,460
‫ambos se usan y, por

160
00:07:26,460 --> 00:07:29,510
‫lo tanto, es importante que los conozca todos.

161
00:07:29,510 --> 00:07:33,070
‫De todos modos, en el formulario referenciado mantenemos dos conjuntos de

162
00:07:33,070 --> 00:07:35,826
‫datos relacionados y todos los documentos separados.

163
00:07:35,826 --> 00:07:39,589
‫Entonces, nuevamente, todos los datos están bien separados,

164
00:07:39,589 --> 00:07:43,275
‫que es exactamente lo que significa normalizado.

165
00:07:43,275 --> 00:07:47,110
‫Continuando, el ejemplo de la base de datos de películas de

166
00:07:47,110 --> 00:07:50,750
‫antes tendríamos un documento de película y un documento

167
00:07:50,750 --> 00:07:54,870
‫de actor para cada actor. Ahora, ¿cómo haríamos la conexión

168
00:07:54,870 --> 00:07:58,710
‫entre la película y los actores para que luego en nuestra aplicación

169
00:07:58,710 --> 00:08:02,150
‫podamos mostrar qué actores interpretaron en una película en particular?

170
00:08:02,150 --> 00:08:05,210
‫Porque si todos son documentos completamente diferentes, la película no tiene

171
00:08:05,210 --> 00:08:09,438
‫forma de conocer a los actores. Derecha.

172
00:08:09,438 --> 00:08:12,253
‫Bueno, ahí es donde entran las identificaciones.

173
00:08:12,253 --> 00:08:16,460
‫Entonces usamos los ID de actor para crear referencias en el

174
00:08:16,460 --> 00:08:18,020
‫documento de la película.

175
00:08:18,020 --> 00:08:20,981
‫Conectando películas con actores de manera efectiva.

176
00:08:20,981 --> 00:08:24,760
‫Entonces ves que en un documento de película tenemos una matriz

177
00:08:24,760 --> 00:08:27,198
‫donde almacenamos las identificaciones de todos los

178
00:08:27,198 --> 00:08:30,760
‫actores para que cuando solicitemos datos sobre cierta película podamos

179
00:08:30,760 --> 00:08:34,553
‫identificar fácilmente a sus actores. ¿Tiene sentido?

180
00:08:34,553 --> 00:08:38,830
‫Ahora bien, este tipo de referencia se llama referencia secundaria porque es el

181
00:08:38,830 --> 00:08:41,480
‫padre en este caso la película que hace

182
00:08:41,480 --> 00:08:45,104
‫referencia a sus hijos. En este caso los actores.

183
00:08:45,104 --> 00:08:48,841
‫Entonces realmente estamos creando una especie de jerarquía aquí. Derecha.

184
00:08:48,841 --> 00:08:51,870
‫Ahora también hay referencias de padres y hablaremos

185
00:08:51,870 --> 00:08:54,390
‫de eso un poco más tarde.

186
00:08:54,390 --> 00:08:58,710
‫Y por cierto en bases de datos relacionales; todos los datos siempre

187
00:08:58,710 --> 00:09:01,958
‫se representan en forma normalizada de esta manera.

188
00:09:01,958 --> 00:09:05,490
‫Pero en una base de datos sin secuelas

189
00:09:05,490 --> 00:09:09,700
‫como MongoDB, podemos desnormalizar los datos en una forma

190
00:09:09,700 --> 00:09:12,450
‫desnormalizada simplemente incrustando el documento

191
00:09:12,450 --> 00:09:15,330
‫relacionado directamente en el documento principal.

192
00:09:15,330 --> 00:09:18,330
‫Así que ahora tenemos todos los datos

193
00:09:18,330 --> 00:09:22,060
‫relevantes sobre los actores dentro de un documento de película principal

194
00:09:22,060 --> 00:09:25,700
‫sin la necesidad de documentos, colecciones e identificaciones por separado.

195
00:09:25,700 --> 00:09:30,088
‫Entonces, nuevamente, si elegimos desnormalizar o incrustar nuestros datos, tendremos un

196
00:09:30,088 --> 00:09:34,280
‫documento principal que contiene todos los datos principales, así como

197
00:09:34,280 --> 00:09:37,197
‫los datos relacionados. Está bien.

198
00:09:37,197 --> 00:09:40,340
‫Y el resultado de esto es que nuestra aplicación

199
00:09:40,340 --> 00:09:43,330
‫necesitará menos consultas a la base de datos.

200
00:09:43,330 --> 00:09:45,000
‫Porque podemos obtener

201
00:09:45,000 --> 00:09:48,074
‫todos los datos sobre películas y actores al

202
00:09:48,074 --> 00:09:51,650
‫mismo tiempo, lo que, por supuesto, aumentará nuestro rendimiento.

203
00:09:51,650 --> 00:09:53,840
‫Ahora, la desventaja aquí es, por

204
00:09:53,840 --> 00:09:57,530
‫supuesto, que realmente no podemos consultar los datos incrustados por sí solos.

205
00:09:57,530 --> 00:10:00,810
‫Entonces, si ese es un requisito para la aplicación,

206
00:10:00,810 --> 00:10:03,790
‫tendría que elegir un diseño normalizado y, dado

207
00:10:03,790 --> 00:10:06,280
‫que estamos hablando de los pros y

208
00:10:06,280 --> 00:10:09,030
‫los contras de la forma desnormalizada; hagamos lo

209
00:10:09,030 --> 00:10:11,490
‫mismo con el diseño normalizado.

210
00:10:11,490 --> 00:10:13,920
‫Y básicamente es todo lo contrario de

211
00:10:13,920 --> 00:10:15,770
‫lo que acabamos de hablar.

212
00:10:15,770 --> 00:10:18,319
‫Por lo tanto, hay una mejora en

213
00:10:18,319 --> 00:10:22,390
‫el rendimiento cuando a menudo necesitamos consultar los datos relacionados por sí

214
00:10:22,390 --> 00:10:25,740
‫mismos porque luego podemos consultar los datos que necesitamos y

215
00:10:25,740 --> 00:10:28,490
‫no siempre las películas y los actores juntos.

216
00:10:28,490 --> 00:10:31,640
‫Pero en la otra mano; cuando realmente necesitemos consultar

217
00:10:31,640 --> 00:10:33,906
‫películas y actores juntos, entonces necesitaremos

218
00:10:33,906 --> 00:10:36,396
‫muchas consultas a la base de datos.

219
00:10:36,396 --> 00:10:40,010
‫Entonces, primero la consulta para la película y luego a partir de

220
00:10:40,010 --> 00:10:42,610
‫ahí también necesitaremos una consulta para el actor y

221
00:10:42,610 --> 00:10:44,989
‫eso, por supuesto, funciona para el rendimiento.

222
00:10:44,989 --> 00:10:48,328
‫Entonces, al diseñar su base de datos; este es el tipo de cosas que

223
00:10:48,328 --> 00:10:50,569
‫debe tener en cuenta. Está bien.

224
00:10:50,569 --> 00:10:54,900
‫Y ahora solo como nota al margen; Por supuesto, podríamos comenzar nuestro proceso

225
00:10:54,900 --> 00:10:56,994
‫de pensamiento con datos desnormalizados y

226
00:10:56,994 --> 00:10:59,670
‫luego llegar a la conclusión de que es

227
00:10:59,670 --> 00:11:01,692
‫mejor normalizar los datos.

228
00:11:01,692 --> 00:11:05,043
‫Entonces, cuando pensamos en nuestro modelo de datos, esta forma de

229
00:11:05,043 --> 00:11:08,378
‫organizar los datos funciona, por supuesto, en ambos sentidos.

230
00:11:08,378 --> 00:11:12,570
‫Ahora bien, ¿cómo decidimos realmente si debemos normalizar

231
00:11:12,570 --> 00:11:15,330
‫o desnormalizar los datos?

232
00:11:15,330 --> 00:11:18,033
‫Bueno, eso es exactamente lo que aprenderemos a continuación.

233
00:11:19,690 --> 00:11:22,974
‫Entonces, cuando tenemos dos conjuntos de datos relacionados; tenemos que decidir

234
00:11:22,974 --> 00:11:26,180
‫si vamos a incrustar los conjuntos de datos o si

235
00:11:26,180 --> 00:11:27,693
‫los mantendremos separados y

236
00:11:27,693 --> 00:11:30,400
‫referenciarlos de un conjunto de datos a otro.

237
00:11:30,400 --> 00:11:32,730
‫Y como que desarrollé este marco

238
00:11:32,730 --> 00:11:36,070
‫de decisión, les mostraré dónde usamos tres criterios para

239
00:11:36,070 --> 00:11:37,770
‫tomar esa decisión.

240
00:11:37,770 --> 00:11:40,450
‫Primero, analizamos el tipo de relaciones que

241
00:11:40,450 --> 00:11:42,800
‫existen entre los conjuntos de datos.

242
00:11:42,800 --> 00:11:45,856
‫En segundo lugar, intentamos determinar el patrón de acceso

243
00:11:45,856 --> 00:11:50,150
‫a los datos del conjunto de datos que queremos incrustar o hacer referencia.

244
00:11:50,150 --> 00:11:53,320
‫Y esto solo significa analizar la frecuencia con la que se leen y

245
00:11:53,320 --> 00:11:55,282
‫escriben los datos en ese conjunto de datos.

246
00:11:55,282 --> 00:11:59,025
‫Luego también miramos algo que yo llamo cercanía de datos.

247
00:11:59,025 --> 00:12:02,940
‫Y la cercanía de datos es un término que acabo de inventar,

248
00:12:02,940 --> 00:12:06,870
‫pero lo que significa es cuánto están realmente relacionados los datos y cómo

249
00:12:06,870 --> 00:12:10,109
‫queremos consultar los datos de la base de datos.

250
00:12:10,109 --> 00:12:11,850
‫Y esto tendrá más sentido

251
00:12:11,850 --> 00:12:14,180
‫cuando hablemos de ello en un momento.

252
00:12:14,180 --> 00:12:17,330
‫Ahora para tomar realmente la decisión; Necesitamos combinar todos estos

253
00:12:17,330 --> 00:12:19,350
‫tres criterios y no usar

254
00:12:19,350 --> 00:12:21,792
‫solo uno de ellos de forma aislada.

255
00:12:21,792 --> 00:12:25,230
‫Así por ejemplo; El hecho de que el criterio número

256
00:12:25,230 --> 00:12:28,380
‫uno diga incrustar no significa que no necesitemos

257
00:12:28,380 --> 00:12:30,425
‫mirar los otros dos criterios.

258
00:12:30,425 --> 00:12:34,124
‫Muy bien y comencemos con el tipo de relación.

259
00:12:34,124 --> 00:12:37,968
‫Entonces, por lo general, cuando tenemos una relación de uno a pocos,

260
00:12:37,968 --> 00:12:40,700
‫siempre incorporamos el conjunto de datos relacionado en el

261
00:12:40,700 --> 00:12:43,430
‫conjunto de datos principal, tal como aprendimos en

262
00:12:43,430 --> 00:12:45,860
‫la última diapositiva. Derecha.

263
00:12:45,860 --> 00:12:49,110
‫Ahora en una relación de uno a muchos; las cosas son

264
00:12:49,110 --> 00:12:52,880
‫un poco más borrosas, por lo que está bien incrustar o hacer referencia.

265
00:12:52,880 --> 00:12:55,140
‫En ese caso tendremos que decidir

266
00:12:55,140 --> 00:12:57,304
‫según los otros dos criterios.

267
00:12:57,304 --> 00:12:59,825
‫Ahora, por otro lado, en una relación

268
00:12:59,825 --> 00:13:03,894
‫de uno a una tonelada o de muchos a muchos, generalmente siempre hacemos

269
00:13:03,894 --> 00:13:06,811
‫referencia a los datos. Eso es porque si realmente

270
00:13:06,811 --> 00:13:10,004
‫hiciéramos incrustaciones en este caso, podríamos crear rápidamente un documento demasiado grande.

271
00:13:10,004 --> 00:13:14,902
‫Incluso superando potencialmente el máximo de 16 megabytes.

272
00:13:14,902 --> 00:13:18,214
‫Entonces, la solución para eso es, por supuesto, hacer referencia

273
00:13:18,214 --> 00:13:22,090
‫a los datos o normalizarlos. Y como un ejemplo rápido;

274
00:13:22,090 --> 00:13:24,142
‫digamos que en nuestro ejemplo de base

275
00:13:24,142 --> 00:13:27,830
‫de datos de películas tenemos alrededor de 100 imágenes asociadas a cada película.

276
00:13:27,830 --> 00:13:30,874
‫Entonces, podríamos decir que es una relación de uno a

277
00:13:30,874 --> 00:13:34,230
‫muchos, pero ¿vamos a incrustar el conjunto de datos o deberíamos

278
00:13:34,230 --> 00:13:37,523
‫hacer referencia a ellos aquí? Bueno, realmente no lo sabemos.

279
00:13:37,523 --> 00:13:40,571
‫Así que echemos un vistazo a los otros dos criterios.

280
00:13:40,571 --> 00:13:44,420
‫Entonces, el segundo trata sobre los patrones de acceso a datos,

281
00:13:44,420 --> 00:13:46,290
‫donde es solo una

282
00:13:46,290 --> 00:13:48,242
‫descripción elegante para evaluar si un

283
00:13:48,242 --> 00:13:51,559
‫determinado conjunto de datos se escribe o se lee principalmente.

284
00:13:51,559 --> 00:13:55,760
‫Entonces, si el conjunto de datos sobre el que estamos decidiendo se

285
00:13:55,760 --> 00:13:58,179
‫lee principalmente y los datos no

286
00:13:58,179 --> 00:14:01,620
‫se actualizan mucho, probablemente deberíamos incrustar ese conjunto de datos.

287
00:14:01,620 --> 00:14:04,690
‫Entonces, una alta proporción de lectura / escritura solo significa

288
00:14:04,690 --> 00:14:07,100
‫que hay mucha más lectura que escritura.

289
00:14:07,100 --> 00:14:11,100
‫Y una vez más, un conjunto de datos como ese es un buen candidato

290
00:14:11,100 --> 00:14:11,983
‫para la incrustación.

291
00:14:12,830 --> 00:14:15,980
‫La razón de esto es que al incrustar solo necesitamos un

292
00:14:15,980 --> 00:14:18,379
‫viaje a la base de datos por consulta.

293
00:14:18,379 --> 00:14:22,197
‫Mientras que para hacer referencia necesitamos dos viajes. Derecha.

294
00:14:22,197 --> 00:14:25,660
‫Entonces, si incrustamos datos que se leen mucho; en cada consulta,

295
00:14:25,660 --> 00:14:28,383
‫guardamos un viaje a la base de

296
00:14:28,383 --> 00:14:32,147
‫datos, lo que hace que todo el proceso sea mucho más eficiente.

297
00:14:32,147 --> 00:14:35,260
‫Así que creo que nuestro ejemplo de imagen de

298
00:14:35,260 --> 00:14:38,320
‫película sería un buen candidato para incrustar.

299
00:14:38,320 --> 00:14:41,543
‫Porque una vez que las 100 imágenes se guardan en

300
00:14:41,543 --> 00:14:43,920
‫la base de datos, ya no se

301
00:14:43,920 --> 00:14:46,930
‫actualizan realmente porque realmente no hay nada que actualizar

302
00:14:46,930 --> 00:14:50,057
‫sobre una imagen. Bien, todo se

303
00:14:50,057 --> 00:14:52,563
‫trata de leer y, por lo tanto,

304
00:14:52,563 --> 00:14:55,501
‫según este criterio, incrustaríamos los documentos con imágenes.

305
00:14:55,501 --> 00:14:59,092
‫Ahora, por otro lado, si nuestros datos se

306
00:14:59,092 --> 00:15:03,118
‫actualizan mucho, entonces deberíamos considerar hacer referencia o normalizar los datos.

307
00:15:03,118 --> 00:15:06,700
‫Eso es porque es más trabajo para el motor de base

308
00:15:06,700 --> 00:15:08,870
‫de datos actualizar e incrustar

309
00:15:08,870 --> 00:15:11,600
‫un documento que un documento independiente más simple.

310
00:15:11,600 --> 00:15:13,980
‫Y dado que nuestro principal objetivo es el rendimiento;

311
00:15:13,980 --> 00:15:15,917
‫simplemente normalizamos el conjunto de datos.

312
00:15:15,917 --> 00:15:19,653
‫En nuestro ejemplo, digamos que cada película tiene muchas reseñas

313
00:15:19,653 --> 00:15:23,284
‫y el usuario puede marcar cada reseña como útil.

314
00:15:23,284 --> 00:15:27,560
‫Así que cada vez que alguien hace clic en esta revisión fue útil

315
00:15:27,560 --> 00:15:29,780
‫en nuestra aplicación. Necesitamos

316
00:15:29,780 --> 00:15:31,740
‫actualizar el documento correspondiente.

317
00:15:31,740 --> 00:15:35,030
‫Y esto significa que los datos pueden cambiar todo el

318
00:15:35,030 --> 00:15:38,520
‫tiempo, por lo que este es un gran candidato para la normalización.

319
00:15:38,520 --> 00:15:41,420
‫Nuevamente, porque no queremos consultar las películas todo

320
00:15:41,420 --> 00:15:45,190
‫el tiempo si todo lo que realmente queremos actualizar son

321
00:15:45,190 --> 00:15:47,230
‫las reseñas marcándolas como útiles.

322
00:15:47,230 --> 00:15:49,464
‫Vale, ¿eso tiene sentido?

323
00:15:49,464 --> 00:15:53,500
‫Y finalmente al último criterio lo llamo cercanía de datos; que

324
00:15:53,500 --> 00:15:56,320
‫es como una medida de cuánto están

325
00:15:56,320 --> 00:15:59,469
‫relacionados los datos. Entonces, si los

326
00:15:59,469 --> 00:16:02,890
‫dos conjuntos de datos realmente pertenecen juntos de manera

327
00:16:02,890 --> 00:16:05,880
‫intrínseca, probablemente deberían estar integrados entre sí.

328
00:16:05,880 --> 00:16:10,440
‫En nuestro ejemplo; Todos los usuarios pueden tener muchas direcciones de correo electrónico

329
00:16:10,440 --> 00:16:13,780
‫en su cuenta y, dado que están tan intrínsecamente

330
00:16:13,780 --> 00:16:17,190
‫conectados al usuario, no hay duda de que los correos

331
00:16:17,190 --> 00:16:19,920
‫electrónicos deben estar integrados en el documento.

332
00:16:19,920 --> 00:16:23,830
‫Ahora bien, si con frecuencia necesitamos consultar ambos conjuntos de datos por sí

333
00:16:23,830 --> 00:16:26,388
‫mismos, entonces esa es una muy buena

334
00:16:26,388 --> 00:16:29,696
‫razón para normalizar los datos en dos conjuntos de datos separados.

335
00:16:29,696 --> 00:16:32,790
‫Incluso si están estrechamente relacionados.

336
00:16:32,790 --> 00:16:35,227
‫Así que imagina que en nuestra aplicación

337
00:16:35,227 --> 00:16:40,227
‫tenemos un cuestionario en el que los usuarios tienen que identificar una película basada en imágenes.

338
00:16:40,440 --> 00:16:43,080
‫Esto significa que vamos a consultar muchas imágenes

339
00:16:43,080 --> 00:16:44,180
‫por su cuenta.

340
00:16:44,180 --> 00:16:47,756
‫Así que sin tener que consultar necesariamente las películas en sí.

341
00:16:47,756 --> 00:16:50,640
‫Y así si aplicamos este tercer criterio; llegamos a

342
00:16:50,640 --> 00:16:54,137
‫la conclusión de que en realidad deberíamos normalizar el conjunto de

343
00:16:54,137 --> 00:16:56,759
‫datos de imágenes. Está bien.

344
00:16:56,759 --> 00:17:00,770
‫Porque de nuevo si implementamos esta funcionalidad de cuestionario; las

345
00:17:00,770 --> 00:17:04,057
‫imágenes se consultarán solas todo el tiempo.

346
00:17:04,057 --> 00:17:07,422
‫Entonces, todo esto muestra que realmente deberíamos mirar los

347
00:17:07,422 --> 00:17:09,850
‫tres criterios juntos en lugar

348
00:17:09,850 --> 00:17:12,700
‫de solo uno de ellos de forma aislada.

349
00:17:12,700 --> 00:17:15,841
‫Porque eso podría llevar a decisiones menos óptimas.

350
00:17:15,841 --> 00:17:18,908
‫Y digo menos óptimas en lugar de incorrectas

351
00:17:18,908 --> 00:17:21,766
‫porque en realidad no son formas

352
00:17:21,766 --> 00:17:25,262
‫completamente correctas o completamente incorrectas de modelar nuestros datos.

353
00:17:25,262 --> 00:17:28,970
‫No hay reglas estrictas; estas son solo pautas que puede

354
00:17:28,970 --> 00:17:31,380
‫seguir para encontrar la forma

355
00:17:31,380 --> 00:17:33,860
‫probablemente más correcta de estructurar sus datos.

356
00:17:33,860 --> 00:17:37,077
‫Pero, de nuevo, es difícil estar realmente equivocado.

357
00:17:37,077 --> 00:17:38,253
‫¿Okey?

358
00:17:39,740 --> 00:17:43,110
‫Ahora, digamos que hemos optado por normalizar nuestros conjuntos

359
00:17:43,110 --> 00:17:44,270
‫de datos.

360
00:17:44,270 --> 00:17:46,653
‫En otras palabras, hacer referencia a los datos.

361
00:17:46,653 --> 00:17:49,380
‫Luego, después de eso, todavía tenemos

362
00:17:49,380 --> 00:17:52,840
‫que elegir entre tres tipos diferentes de referencias.

363
00:17:52,840 --> 00:17:55,460
‫Referencias de niños, referencias de padres

364
00:17:55,460 --> 00:17:57,540
‫y referencias bidireccionales.

365
00:17:57,540 --> 00:18:00,767
‫Entonces, el primer tipo es la referencia a niños.

366
00:18:00,767 --> 00:18:04,440
‫Cuál es el tipo de referencia que te mostré antes.

367
00:18:04,440 --> 00:18:05,470
‫¿Okey?

368
00:18:05,470 --> 00:18:07,850
‫Y no tomemos el ejemplo de registro de errores

369
00:18:07,850 --> 00:18:10,128
‫que mencioné anteriormente. Donde potencialmente

370
00:18:10,128 --> 00:18:13,021
‫podríamos tener millones de documentos bloqueados.

371
00:18:13,021 --> 00:18:17,300
‫Así que en referencia infantil; Básicamente, mantenemos referencias a los

372
00:18:17,300 --> 00:18:20,460
‫documentos secundarios relacionados en un documento principal.

373
00:18:20,460 --> 00:18:22,941
‫Y generalmente se almacenan en una matriz.

374
00:18:22,941 --> 00:18:25,735
‫Entonces ve que cada registro tiene una ID y

375
00:18:25,735 --> 00:18:29,040
‫luego en el documento de la aplicación hay esa matriz con

376
00:18:29,040 --> 00:18:31,358
‫todas estas ID. ¿Derecha?

377
00:18:31,358 --> 00:18:34,400
‫Sin embargo, el problema aquí es que

378
00:18:34,400 --> 00:18:39,320
‫esta matriz de ID puede volverse muy grande si hay muchos niños.

379
00:18:39,320 --> 00:18:42,230
‫Y este es un anti-patrón en MongoDB.

380
00:18:42,230 --> 00:18:45,156
‫Entonces, algo que debemos evitar a toda costa.

381
00:18:45,156 --> 00:18:47,660
‫Además, la referencia de niños hace

382
00:18:47,660 --> 00:18:51,410
‫que los padres y los niños estén muy unidos.

383
00:18:51,410 --> 00:18:54,840
‫Lo que no siempre es lo ideal. Pero esa es exactamente la

384
00:18:54,840 --> 00:18:57,020
‫razón por la que tenemos referencias de padres.

385
00:18:57,020 --> 00:19:00,300
‫Entonces, en referencia a los padres; en realidad

386
00:19:00,300 --> 00:19:01,870
‫funciona al revés.

387
00:19:01,870 --> 00:19:05,570
‫Así que aquí, en cada documento secundario, mantenemos una

388
00:19:05,570 --> 00:19:07,430
‫referencia al elemento principal.

389
00:19:07,430 --> 00:19:10,267
‫Por lo tanto, el nombre de referencia de los padres.

390
00:19:10,267 --> 00:19:13,890
‫En este ejemplo, el ID de la aplicación es 23, por

391
00:19:13,890 --> 00:19:16,640
‫lo que en cada registro está el campo de

392
00:19:16,640 --> 00:19:18,990
‫la aplicación con el ID 23.

393
00:19:18,990 --> 00:19:21,660
‫Para que el niño siempre conozca a su padre.

394
00:19:21,660 --> 00:19:24,920
‫Entonces, en este caso, el padre no sabe nada

395
00:19:24,920 --> 00:19:26,080
‫sobre los hijos.

396
00:19:26,080 --> 00:19:28,768
‫No quiénes son ni cuántos son.

397
00:19:28,768 --> 00:19:32,890
‫Por lo tanto, están mucho más aislados e independientes.

398
00:19:32,890 --> 00:19:35,326
‫En eso, a veces puede ser beneficioso.

399
00:19:35,326 --> 00:19:38,880
‫Entonces, ¿cuál de estos dos tipos es realmente mejor para

400
00:19:38,880 --> 00:19:40,527
‫esta relación de datos?

401
00:19:40,527 --> 00:19:42,820
‫Y recuerde cómo dije que podría haber

402
00:19:42,820 --> 00:19:45,860
‫millones de registros, por lo que supongamos que hay

403
00:19:45,860 --> 00:19:47,652
‫dos millones de documentos registrados.

404
00:19:47,652 --> 00:19:51,340
‫En el caso de referencias de niños, eso significaría que hay dos

405
00:19:51,340 --> 00:19:53,209
‫millones de referencias de ID

406
00:19:53,209 --> 00:19:55,091
‫en el documento de la aplicación.

407
00:19:55,091 --> 00:19:58,300
‫¿Derecha? Ahora también recuerde cómo dije

408
00:19:58,300 --> 00:20:00,545
‫que hay un límite de 16 megabytes en documentos.

409
00:20:00,545 --> 00:20:04,302
‫Entonces, si seguimos agregando y agregando estas ID de niños en

410
00:20:04,302 --> 00:20:06,716
‫la matriz en el padre; entonces

411
00:20:06,716 --> 00:20:09,575
‫alcanzaríamos rápidamente ese límite de 16 megabytes que

412
00:20:09,575 --> 00:20:11,772
‫puede contener cada documento Bson.

413
00:20:11,772 --> 00:20:14,702
‫Simplemente porque esa matriz crecerá mucho.

414
00:20:14,702 --> 00:20:17,210
‫Así que eso no va a funcionar realmente.

415
00:20:17,210 --> 00:20:18,510
‫¿Lo es?

416
00:20:18,510 --> 00:20:20,590
‫Por otro lado, con los padres

417
00:20:20,590 --> 00:20:22,990
‫haciendo referencia a ese problema no sucederá.

418
00:20:22,990 --> 00:20:25,570
‫Simplemente tendremos dos millones de documentos

419
00:20:25,570 --> 00:20:30,540
‫bloqueados como antes, pero cada uno de ellos tiene la identificación de su padre.

420
00:20:30,540 --> 00:20:33,098
‫Pero no hay una matriz que

421
00:20:33,098 --> 00:20:35,740
‫crezca indefinidamente y, por lo tanto, la referencia

422
00:20:35,740 --> 00:20:38,443
‫a los padres sería la mejor solución aquí.

423
00:20:39,380 --> 00:20:41,901
‫Entonces, la conclusión de todo esto es que,

424
00:20:41,901 --> 00:20:44,385
‫en general, la referencia infantil se usa mejor

425
00:20:44,385 --> 00:20:48,008
‫para una o varias relaciones. Donde sabemos de antemano

426
00:20:48,008 --> 00:20:51,118
‫que la variedad de documentos secundarios no crecerá tanto.

427
00:20:51,118 --> 00:20:54,573
‫Por otro lado, la referencia a los padres se usa

428
00:20:54,573 --> 00:20:58,690
‫mejor para relaciones de uno a muchos y de uno a una

429
00:20:58,690 --> 00:21:00,927
‫tonelada como esta. ¿Okey?

430
00:21:00,927 --> 00:21:04,610
‫Entonces, nuevamente, tenga siempre en cuenta que uno de los principios

431
00:21:04,610 --> 00:21:07,920
‫más importantes del modelado de datos de MongoDB

432
00:21:07,920 --> 00:21:11,900
‫es que nunca se debe permitir que la matriz crezca indefinidamente.

433
00:21:11,900 --> 00:21:15,420
‫Para nunca romper ese límite de 16 megabytes.

434
00:21:15,420 --> 00:21:18,170
‫Tampoco queremos enviar a nuestros usuarios una matriz con

435
00:21:18,170 --> 00:21:20,730
‫miles de ID cada vez que soliciten un

436
00:21:20,730 --> 00:21:24,340
‫conjunto de datos principal. ¿Okey?

437
00:21:24,340 --> 00:21:26,900
‫Entonces, ¿esta lógica tiene sentido para ti?

438
00:21:26,900 --> 00:21:29,660
‫Luego pasemos al tercer tipo de referencia

439
00:21:29,660 --> 00:21:31,870
‫que es referencia bidireccional.

440
00:21:31,870 --> 00:21:34,395
‫Y esta vez con el ejemplo de la película y

441
00:21:34,395 --> 00:21:36,380
‫el actor que les mostré cuando hablamos

442
00:21:36,380 --> 00:21:39,364
‫de muchas a muchas relaciones. ¿Recuérdalo?

443
00:21:39,364 --> 00:21:42,229
‫Entonces, nuevamente, cada película tiene muchos actores y

444
00:21:42,229 --> 00:21:44,880
‫cada actor juega en muchas películas.

445
00:21:44,880 --> 00:21:48,464
‫Y esa es una relación típica de muchos a muchos.

446
00:21:48,464 --> 00:21:52,100
‫Y usualmente usamos esta referencia bidireccional para diseñar relaciones

447
00:21:52,100 --> 00:21:55,346
‫de muchos a muchos. Y funciona

448
00:21:55,346 --> 00:21:59,370
‫así; En cada película guardaremos referencias a todos los

449
00:21:59,370 --> 00:22:03,980
‫actores que protagonizan esa película. Así que un poco como en las referencias de niños.

450
00:22:03,980 --> 00:22:07,000
‫Sin embargo y al mismo tiempo en cada actor

451
00:22:07,000 --> 00:22:09,570
‫también guardamos referencias a todas las películas en

452
00:22:09,570 --> 00:22:11,660
‫las que actuó el actor.

453
00:22:11,660 --> 00:22:15,120
‫Entonces, las películas y los actores están conectados en ambas direcciones.

454
00:22:15,120 --> 00:22:17,900
‫Por lo tanto, el nombre de referencia bidireccional.

455
00:22:17,900 --> 00:22:19,950
‫Y esto hace que sea

456
00:22:19,950 --> 00:22:23,290
‫realmente fácil buscar películas y actores de forma completamente independiente.

457
00:22:23,290 --> 00:22:25,910
‫Al mismo tiempo que facilita la búsqueda de

458
00:22:25,910 --> 00:22:29,029
‫los actores asociados a cada película y las películas asociadas

459
00:22:29,029 --> 00:22:30,383
‫a cada actor.

460
00:22:31,623 --> 00:22:32,560
‫(respiración profunda)

461
00:22:32,560 --> 00:22:34,747
‫Esta fue una conferencia bastante larga.

462
00:22:34,747 --> 00:22:38,030
‫Con muchos conceptos nuevos, principios y

463
00:22:38,030 --> 00:22:40,220
‫pautas para recordar.

464
00:22:40,220 --> 00:22:43,460
‫Así que para poder ayudarte con eso; Aquí va un

465
00:22:43,460 --> 00:22:46,650
‫resumen rápido y algunas pautas más generales que puede

466
00:22:46,650 --> 00:22:48,423
‫consultar cuando lo necesite.

467
00:22:49,260 --> 00:22:52,753
‫Entonces, el principio más importante es: estructurar sus datos para que

468
00:22:52,753 --> 00:22:56,120
‫coincidan con las formas en que su aplicación consulta y

469
00:22:56,120 --> 00:22:57,436
‫actualiza los datos.

470
00:22:57,436 --> 00:23:01,400
‫O en otras palabras: identifique primero las preguntas que surjan de los casos

471
00:23:01,400 --> 00:23:03,784
‫de uso de su aplicación y luego

472
00:23:03,784 --> 00:23:06,634
‫modele sus datos para que las preguntas puedan ser

473
00:23:06,634 --> 00:23:08,995
‫respondidas de la manera más eficiente.

474
00:23:08,995 --> 00:23:12,610
‫Por ejemplo; cuando necesito consultar películas y actores siempre

475
00:23:12,610 --> 00:23:16,130
‫juntos o hay escenarios en los que solo consulto

476
00:23:16,130 --> 00:23:18,041
‫películas o solo actores.

477
00:23:18,041 --> 00:23:20,528
‫Ese tipo de preguntas es en qué

478
00:23:20,528 --> 00:23:22,930
‫se basará su modelo de datos.

479
00:23:22,930 --> 00:23:26,730
‫En general, siempre favorezca la incrustación a menos que haya una buena

480
00:23:26,730 --> 00:23:28,440
‫razón para no hacerlo.

481
00:23:28,440 --> 00:23:32,513
‫Especialmente en relaciones de una a pocas y de una a muchas.

482
00:23:33,370 --> 00:23:37,713
‫A continuación, una relación de uno a una tonelada o de muchos a muchos

483
00:23:37,713 --> 00:23:41,543
‫suele ser una buena razón para hacer referencia en lugar de incrustar.

484
00:23:41,543 --> 00:23:45,734
‫Además, favorezca las referencias cuando los datos se actualizan mucho

485
00:23:45,734 --> 00:23:50,717
‫y si necesita acceder con frecuencia a un conjunto de datos por sí solo.

486
00:23:50,717 --> 00:23:55,340
‫Utilice la incrustación cuando la mayoría de los datos se leen pero rara vez se

487
00:23:55,340 --> 00:23:58,469
‫actualizan y cuando dos conjuntos de datos pertenecen intrínsecamente juntos.

488
00:23:58,469 --> 00:24:02,840
‫No permita que las matrices crezcan indefinidamente.

489
00:24:02,840 --> 00:24:05,982
‫Por lo tanto, si desea normalizar; use referencias de

490
00:24:05,982 --> 00:24:09,680
‫niños para relaciones de una a muchas y referencias de padres para

491
00:24:09,680 --> 00:24:11,856
‫relaciones de una a una tonelada.

492
00:24:11,856 --> 00:24:15,160
‫Y finalmente use referencias bidireccionales

493
00:24:15,160 --> 00:24:17,520
‫para muchas relaciones.

494
00:24:17,520 --> 00:24:18,720
‫¿Está bien?

495
00:24:18,720 --> 00:24:21,202
‫Y eso lo resume bastante bien.

496
00:24:21,202 --> 00:24:23,970
‫De hecho, te recomendaría que veas este video

497
00:24:23,970 --> 00:24:27,144
‫dos veces si puedes, solo por lo importante que

498
00:24:27,144 --> 00:24:30,091
‫es este material. ¿Está bien?

499
00:24:30,091 --> 00:24:33,363
‫De todos modos, nos vemos en el siguiente video.