1
00:00:01,180 --> 00:00:02,990
‫Narrador: Uma das etapas mais

2
00:00:02,990 --> 00:00:06,250
‫importantes na construção de aplicativos com uso intensivo de dados é

3
00:00:06,250 --> 00:00:08,700
‫modelar de fato todos esses dados no MongoDB.

4
00:00:08,700 --> 00:00:12,300
‫E é sobre isso que falaremos nesta palestra.

5
00:00:12,300 --> 00:00:14,710
‫Portanto, é realmente crucial que você siga até

6
00:00:14,710 --> 00:00:19,710
‫o fim, mesmo no início, é muito para aceitar. Tudo bem.

7
00:00:19,810 --> 00:00:22,013
‫De qualquer forma, vamos começar agora.

8
00:00:23,530 --> 00:00:27,530
‫Agora, a modelagem de dados é provavelmente um conceito muito novo para você.

9
00:00:27,530 --> 00:00:28,920
‫Portanto, antes de

10
00:00:28,920 --> 00:00:32,070
‫começarmos; vamos deixar claro sobre o que vamos falar.

11
00:00:32,070 --> 00:00:35,656
‫Portanto, modelagem de dados é o processo de pegar dados não

12
00:00:35,656 --> 00:00:38,770
‫estruturados gerados por um cenário do mundo real e, em

13
00:00:38,770 --> 00:00:42,090
‫seguida, estruturá-los em um modelo de dados lógico em um

14
00:00:42,090 --> 00:00:43,410
‫banco de dados.

15
00:00:43,410 --> 00:00:46,300
‫E fazemos isso de acordo com

16
00:00:46,300 --> 00:00:49,330
‫um conjunto de critérios que aprenderemos neste vídeo.

17
00:00:49,330 --> 00:00:51,980
‫Por exemplo; digamos que queremos projetar um modelo

18
00:00:51,980 --> 00:00:54,120
‫de dados de loja online.

19
00:00:54,120 --> 00:00:57,040
‫Haverá inicialmente uma tonelada de dados não estruturados de que

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

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

22
00:00:58,980 --> 00:01:00,900
‫Coisas como produtos, categorias,

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

24
00:01:03,875 --> 00:01:06,300
‫E assim por diante.

25
00:01:06,300 --> 00:01:09,240
‫Nosso objetivo com a modelagem de dados é então estruturar

26
00:01:09,240 --> 00:01:11,450
‫esses dados de uma maneira lógica.

27
00:01:11,450 --> 00:01:14,090
‫Refletindo os relacionamentos do mundo real

28
00:01:14,090 --> 00:01:16,920
‫que existem entre alguns desses conjuntos de dados.

29
00:01:16,920 --> 00:01:19,670
‫Um pouco como você pode ver neste exemplo.

30
00:01:19,670 --> 00:01:23,110
‫E é claro que isso é apenas um tipo de situação imaginária, mas

31
00:01:23,110 --> 00:01:24,320
‫essa é a ideia.

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

33
00:01:25,600 --> 00:01:28,940
‫Agora, muitos desenvolvedores de back-end dizem que a modelagem de dados

34
00:01:28,940 --> 00:01:30,930
‫é onde devemos pensar mais.

35
00:01:30,930 --> 00:01:33,670
‫Essa é a parte mais exigente de

36
00:01:33,670 --> 00:01:35,310
‫construir um aplicativo inteiro.

37
00:01:35,310 --> 00:01:38,100
‫Porque realmente nem sempre é direto.

38
00:01:38,100 --> 00:01:41,070
‫E às vezes simplesmente não há respostas certas.

39
00:01:41,070 --> 00:01:45,500
‫Portanto, não apenas uma maneira correta de estruturar os dados.

40
00:01:45,500 --> 00:01:48,420
‫Mas de qualquer forma, farei o meu melhor para estabelecer o

41
00:01:48,420 --> 00:01:49,510
‫processo neste vídeo.

42
00:01:49,510 --> 00:01:52,367
‫E para isso vamos passar por quatro etapas.

43
00:01:52,367 --> 00:01:56,200
‫Então, na primeira etapa; aprendemos como identificar diferentes

44
00:01:56,200 --> 00:01:59,340
‫tipos de relacionamento entre os dados.

45
00:01:59,340 --> 00:02:00,360
‫Então,

46
00:02:00,360 --> 00:02:03,019
‫vamos entender a diferença entre

47
00:02:03,019 --> 00:02:07,163
‫referência ou normalização e incorporação ou desnormalização.

48
00:02:07,163 --> 00:02:09,030
‫Na próxima e

49
00:02:09,030 --> 00:02:11,660
‫mais importante etapa; Mostrarei minha estrutura para

50
00:02:11,660 --> 00:02:13,560
‫decidir se devemos incorporar documentos

51
00:02:13,560 --> 00:02:15,750
‫ou fazer referência a outros

52
00:02:15,750 --> 00:02:18,690
‫documentos com base em alguns fatores diferentes.

53
00:02:18,690 --> 00:02:20,810
‫Além disso, temos que falar rapidamente sobre

54
00:02:20,810 --> 00:02:22,680
‫os diferentes tipos de referência.

55
00:02:22,680 --> 00:02:25,920
‫Porque isso é importante se esse for o tipo de

56
00:02:25,920 --> 00:02:28,220
‫design que escolhemos para nossos dados.

57
00:02:28,220 --> 00:02:32,290
‫Portanto, esta vai ser na verdade uma aula bastante teórica.

58
00:02:32,290 --> 00:02:35,940
‫Mas também absolutamente essencial para o seu progresso como

59
00:02:35,940 --> 00:02:37,660
‫desenvolvedor de back-end.

60
00:02:37,660 --> 00:02:41,553
‫Porque a maneira como projetamos dados, a maneira como modelamos nossos

61
00:02:41,553 --> 00:02:45,180
‫dados pode fazer ou quebrar todo o nosso aplicativo.

62
00:02:45,180 --> 00:02:47,950
‫E haverá muitos exemplos ao longo do caminho para

63
00:02:47,950 --> 00:02:49,510
‫tornar esse processo mais fácil.

64
00:02:49,510 --> 00:02:50,343
‫Tudo bem.

65
00:02:51,320 --> 00:02:53,440
‫E a primeira coisa sobre

66
00:02:53,440 --> 00:02:55,780
‫a qual falaremos são os diferentes tipos

67
00:02:55,780 --> 00:02:58,210
‫de relacionamento que podem existir entre os dados.

68
00:02:58,210 --> 00:03:00,780
‫Portanto, existem três grandes tipos de relacionamento.

69
00:03:00,780 --> 00:03:05,150
‫Um para um, um para muitos e muitos para muitos.

70
00:03:05,150 --> 00:03:06,990
‫E vou usar um aplicativo

71
00:03:06,990 --> 00:03:08,890
‫de filme como exemplo neste slide.

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

73
00:03:10,000 --> 00:03:12,440
‫Portanto, primeiro uma relação um para um

74
00:03:12,440 --> 00:03:14,140
‫entre os dados é

75
00:03:14,140 --> 00:03:17,370
‫basicamente quando um campo só pode ter um valor.

76
00:03:17,370 --> 00:03:21,550
‫Portanto, em nosso exemplo de aplicação de filme; um filme só

77
00:03:21,550 --> 00:03:22,990
‫tem um nome.

78
00:03:22,990 --> 00:03:24,910
‫E, portanto, este é um

79
00:03:24,910 --> 00:03:27,160
‫exemplo simples de relacionamento um para um.

80
00:03:27,160 --> 00:03:29,690
‫Mas esses relacionamentos não são realmente importantes em

81
00:03:29,690 --> 00:03:31,363
‫termos de modelagem de dados.

82
00:03:32,330 --> 00:03:34,430
‫Agora, os relacionamentos mais

83
00:03:34,430 --> 00:03:37,210
‫importantes são um para muitos relacionamentos.

84
00:03:37,210 --> 00:03:39,770
‫E eles são tão importantes que no

85
00:03:39,770 --> 00:03:42,510
‫MongoDB realmente distinguimos entre três tipos de

86
00:03:42,510 --> 00:03:44,540
‫relacionamentos um para muitos.

87
00:03:44,540 --> 00:03:49,540
‫Um para alguns, um para muitos e um para uma tonelada ou um

88
00:03:49,910 --> 00:03:53,230
‫milhão ou algo assim. Portanto, a diferença aqui é

89
00:03:53,230 --> 00:03:56,893
‫baseada na quantidade relativa de muitos. Tudo bem.

90
00:03:57,840 --> 00:04:00,969
‫Portanto, um exemplo para um relacionamento de um

91
00:04:00,969 --> 00:04:05,967
‫para alguns é que um filme pode ganhar muitos prêmios, mas na verdade apenas alguns.

92
00:04:05,967 --> 00:04:09,630
‫Portanto, o filme não vai ganhar mil prêmios, mas

93
00:04:09,630 --> 00:04:11,220
‫pode ganhar alguns.

94
00:04:11,220 --> 00:04:14,930
‫E então este é um relacionamento típico de um para poucos.

95
00:04:14,930 --> 00:04:18,710
‫Portanto, você vê que, em geral, um relacionamento de um

96
00:04:18,710 --> 00:04:23,210
‫para muitos significa que um documento pode estar relacionado a muitos outros documentos.

97
00:04:23,210 --> 00:04:26,680
‫Agora, isso pode parecer um pouco abstrato sem os dados JSON, mas

98
00:04:26,680 --> 00:04:28,480
‫esse é realmente o propósito aqui.

99
00:04:28,480 --> 00:04:31,040
‫Eu só quero mostrar a vocês uma

100
00:04:31,040 --> 00:04:33,759
‫visão geral conceitual desses diferentes tipos de relacionamento.

101
00:04:33,759 --> 00:04:36,872
‫De qualquer forma, qualquer relacionamento um para muitos

102
00:04:36,872 --> 00:04:40,600
‫um documento pode se relacionar a centenas ou milhares

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

104
00:04:42,070 --> 00:04:44,788
‫Por exemplo; um filme pode ter milhares de

105
00:04:44,788 --> 00:04:46,710
‫comentários em nosso aplicativo.

106
00:04:46,710 --> 00:04:49,380
‫E, portanto, este não é realmente um relacionamento de um para poucos, mas

107
00:04:49,380 --> 00:04:51,524
‫de um para muitos. OK?

108
00:04:51,524 --> 00:04:55,616
‫E, finalmente, temos o relacionamento de um para outro.

109
00:04:55,616 --> 00:04:59,720
‫Imagine que queremos implementar alguma funcionalidade de registro

110
00:04:59,720 --> 00:05:03,110
‫em nosso aplicativo. Então, basicamente, para saber exatamente

111
00:05:03,110 --> 00:05:04,870
‫o que está acontecendo em nosso servidor.

112
00:05:04,870 --> 00:05:08,770
‫Esses logs podem facilmente crescer para milhões de documentos.

113
00:05:08,770 --> 00:05:11,270
‫E então este é um exemplo

114
00:05:11,270 --> 00:05:14,200
‫muito típico de um relacionamento de um para outro.

115
00:05:14,200 --> 00:05:17,100
‫E a diferença entre muitos e uma tonelada é,

116
00:05:17,100 --> 00:05:20,730
‫claro, um pouco confusa, mas pense que se algo pode crescer

117
00:05:20,730 --> 00:05:23,360
‫quase até o infinito, então é definitivamente uma

118
00:05:23,360 --> 00:05:25,532
‫relação de um para uma tonelada.

119
00:05:25,532 --> 00:05:28,763
‫Portanto, novamente, os relacionamentos de um para muitos

120
00:05:28,763 --> 00:05:31,650
‫são os mais importantes a se conhecer.

121
00:05:31,650 --> 00:05:34,050
‫Por falar nisso; em bancos de

122
00:05:34,050 --> 00:05:37,061
‫dados relacionais, há apenas um para muitos, sem

123
00:05:37,061 --> 00:05:39,800
‫quantificar o quanto esse número realmente é.

124
00:05:39,800 --> 00:05:41,800
‫Em bancos de dados MongoDB,

125
00:05:41,800 --> 00:05:44,010
‫porém, é uma diferença extremamente importante.

126
00:05:44,010 --> 00:05:47,150
‫Porque é um dos fatores que usaremos para

127
00:05:47,150 --> 00:05:49,891
‫decidir se devemos desnormalizar ou normalizar

128
00:05:49,891 --> 00:05:53,340
‫os dados, como você aprenderá um pouco mais tarde.

129
00:05:53,340 --> 00:05:57,181
‫De qualquer forma, o menor tipo de relacionamento é o de muitos para

130
00:05:57,181 --> 00:06:00,149
‫muitos em que um filme pode ter muitos atores.

131
00:06:00,149 --> 00:06:04,876
‫Mas, ao mesmo tempo, um ator pode atuar em muitos filmes.

132
00:06:04,876 --> 00:06:07,910
‫E aqui o relacionamento basicamente segue em

133
00:06:07,910 --> 00:06:09,630
‫ambas as direções.

134
00:06:09,630 --> 00:06:11,800
‫Onde antes, nos outros tipos, era

135
00:06:11,800 --> 00:06:13,939
‫apenas em uma direção.

136
00:06:13,939 --> 00:06:17,470
‫Por exemplo, um filme pode ter muitas críticas, mas uma

137
00:06:17,470 --> 00:06:22,450
‫específica é apenas para aquele filme. Direito.

138
00:06:22,450 --> 00:06:24,560
‫E o mesmo vale para os prêmios.

139
00:06:24,560 --> 00:06:27,506
‫Portanto, um prêmio específico, como o de

140
00:06:27,506 --> 00:06:30,914
‫melhor ator, vai para apenas um filme, não para vários.

141
00:06:30,914 --> 00:06:35,580
‫Mas com filmes e atores é realmente diferente.

142
00:06:35,580 --> 00:06:39,250
‫Então, novamente, um filme é estrelado por muitos atores, mas

143
00:06:39,250 --> 00:06:41,920
‫um ator representa muitos filmes e,

144
00:06:41,920 --> 00:06:45,020
‫portanto, é um relacionamento de muitos para muitos.

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

146
00:06:46,170 --> 00:06:49,060
‫Portanto, mantenha tudo isso em mente enquanto avançamos

147
00:06:49,060 --> 00:06:50,063
‫nesta palestra.

148
00:06:51,760 --> 00:06:54,870
‫E provavelmente o aspecto mais importante que precisamos aprender

149
00:06:54,870 --> 00:06:57,900
‫sobre os bancos de dados MongoDB é referenciar

150
00:06:57,900 --> 00:07:00,340
‫e incorporar dois conjuntos de dados.

151
00:07:00,340 --> 00:07:02,350
‫E na verdade já falamos

152
00:07:02,350 --> 00:07:05,050
‫um pouco sobre isso antes, mas vamos revisá-lo aqui

153
00:07:05,050 --> 00:07:07,311
‫e ir um pouco mais fundo também.

154
00:07:07,311 --> 00:07:09,962
‫Portanto, cada vez que temos dois

155
00:07:09,962 --> 00:07:13,829
‫conjuntos de dados relacionados, podemos representar esses dados relacionados

156
00:07:13,829 --> 00:07:18,829
‫em uma referência ou forma normalizada ou em uma forma incorporada ou desnormalizada.

157
00:07:18,842 --> 00:07:22,190
‫E continuo usando os dois termos relacionados juntos, como

158
00:07:22,190 --> 00:07:24,340
‫referência e normalização, porque você

159
00:07:24,340 --> 00:07:26,460
‫os verá sendo usados

160
00:07:26,460 --> 00:07:29,510
‫e, portanto, é importante que você os conheça.

161
00:07:29,510 --> 00:07:33,070
‫De qualquer forma, no formulário referenciado mantemos dois conjuntos de

162
00:07:33,070 --> 00:07:35,826
‫dados relacionados e todos os documentos separados.

163
00:07:35,826 --> 00:07:39,589
‫Então, novamente, todos os dados estão bem separados, o

164
00:07:39,589 --> 00:07:43,275
‫que é exatamente o que normalizado significa.

165
00:07:43,275 --> 00:07:47,110
‫Continuando, o exemplo do banco de dados de filmes anterior,

166
00:07:47,110 --> 00:07:50,750
‫teríamos um documento de filme e um documento de

167
00:07:50,750 --> 00:07:54,870
‫ator para cada ator. Agora, como faríamos a conexão

168
00:07:54,870 --> 00:07:58,710
‫entre o filme e os atores para que mais tarde em nosso

169
00:07:58,710 --> 00:08:02,150
‫aplicativo possamos mostrar quais atores atuaram em um determinado filme.

170
00:08:02,150 --> 00:08:05,210
‫Porque se são todos documentos completamente diferentes o filme não

171
00:08:05,210 --> 00:08:09,438
‫tem como saber sobre os atores. Direito.

172
00:08:09,438 --> 00:08:12,253
‫Bem, é aí que entram os IDs.

173
00:08:12,253 --> 00:08:16,460
‫Portanto, usamos os IDs de ator para criar referências no

174
00:08:16,460 --> 00:08:18,020
‫documento do filme.

175
00:08:18,020 --> 00:08:20,981
‫Conectando efetivamente filmes com atores.

176
00:08:20,981 --> 00:08:24,760
‫Então, você vê que em um documento de filme temos uma matriz

177
00:08:24,760 --> 00:08:27,198
‫onde armazenamos os IDs de todos os

178
00:08:27,198 --> 00:08:30,760
‫atores para que, quando solicitamos dados sobre um determinado filme,

179
00:08:30,760 --> 00:08:34,553
‫possamos identificar facilmente seus atores. Isso faz sentido?

180
00:08:34,553 --> 00:08:38,830
‫Agora, esse tipo de referência é chamado de referência filho porque é

181
00:08:38,830 --> 00:08:41,480
‫o pai, neste caso, o filme que faz

182
00:08:41,480 --> 00:08:45,104
‫referência a seus filhos. Neste caso, os atores.

183
00:08:45,104 --> 00:08:48,841
‫Então, estamos realmente criando algum tipo de hierarquia aqui. Direito.

184
00:08:48,841 --> 00:08:51,870
‫Agora também há referência aos pais e falaremos

185
00:08:51,870 --> 00:08:54,390
‫sobre isso um pouco mais tarde.

186
00:08:54,390 --> 00:08:58,710
‫E, por falar nisso, em bancos de dados relacionais; todos os

187
00:08:58,710 --> 00:09:01,958
‫dados são sempre representados na forma normalizada assim.

188
00:09:01,958 --> 00:09:05,490
‫Mas em um banco de dados sem sequência

189
00:09:05,490 --> 00:09:09,700
‫como o MongoDB, podemos desnormalizar os dados em uma

190
00:09:09,700 --> 00:09:12,450
‫forma desnormalizada simplesmente incorporando o

191
00:09:12,450 --> 00:09:15,330
‫documento relacionado diretamente ao documento principal.

192
00:09:15,330 --> 00:09:18,330
‫Portanto, agora temos todos os dados relevantes

193
00:09:18,330 --> 00:09:22,060
‫sobre os atores dentro de um documento principal do filme,

194
00:09:22,060 --> 00:09:25,700
‫sem a necessidade de documentos, coleções e IDs separados.

195
00:09:25,700 --> 00:09:30,088
‫Portanto, novamente, se escolhermos desnormalizar ou incorporar nossos dados, teremos um

196
00:09:30,088 --> 00:09:34,280
‫documento principal contendo todos os dados principais, bem como

197
00:09:34,280 --> 00:09:37,197
‫os dados relacionados. Tudo bem.

198
00:09:37,197 --> 00:09:40,340
‫E o resultado disso é que nosso aplicativo precisará

199
00:09:40,340 --> 00:09:43,330
‫de menos consultas ao banco de dados.

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

201
00:09:45,000 --> 00:09:48,074
‫todos os dados sobre filmes e atores

202
00:09:48,074 --> 00:09:51,650
‫ao mesmo tempo, o que certamente aumentará nosso desempenho.

203
00:09:51,650 --> 00:09:53,840
‫Agora, a desvantagem aqui é

204
00:09:53,840 --> 00:09:57,530
‫que não podemos realmente consultar os dados incorporados por conta própria.

205
00:09:57,530 --> 00:10:00,810
‫E então, se isso for um requisito para o

206
00:10:00,810 --> 00:10:03,790
‫aplicativo, você terá que escolher um design normalizado,

207
00:10:03,790 --> 00:10:06,280
‫já que estamos falando sobre prós e

208
00:10:06,280 --> 00:10:09,030
‫contras da forma desnormalizada; vamos fazer o

209
00:10:09,030 --> 00:10:11,490
‫mesmo com o design normalizado.

210
00:10:11,490 --> 00:10:13,920
‫E basicamente é o oposto do

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

212
00:10:15,770 --> 00:10:18,319
‫Portanto, há uma melhoria no desempenho

213
00:10:18,319 --> 00:10:22,390
‫quando frequentemente precisamos consultar os dados relacionados por conta própria, porque

214
00:10:22,390 --> 00:10:25,740
‫então podemos apenas consultar os dados de que precisamos

215
00:10:25,740 --> 00:10:28,490
‫e nem sempre filmes e atores juntos.

216
00:10:28,490 --> 00:10:31,640
‫Mas por outro lado; quando precisarmos realmente consultar

217
00:10:31,640 --> 00:10:33,906
‫filmes e atores juntos, precisaremos

218
00:10:33,906 --> 00:10:36,396
‫de muitas consultas ao banco de dados.

219
00:10:36,396 --> 00:10:40,010
‫Portanto, primeiro a consulta para o filme e, a partir daí, também

220
00:10:40,010 --> 00:10:42,610
‫precisaremos de uma consulta para o ator e

221
00:10:42,610 --> 00:10:44,989
‫isso é claro funciona para a performance.

222
00:10:44,989 --> 00:10:48,328
‫Portanto, ao projetar seu banco de dados; esse é o tipo de coisa que você

223
00:10:48,328 --> 00:10:50,569
‫precisa ter em mente. Tudo bem.

224
00:10:50,569 --> 00:10:54,900
‫E agora apenas como uma nota lateral; poderíamos, é claro, começar nosso processo

225
00:10:54,900 --> 00:10:56,994
‫de pensamento com dados desordenados e

226
00:10:56,994 --> 00:10:59,670
‫então chegar à conclusão de que é melhor

227
00:10:59,670 --> 00:11:01,692
‫normalizar de fato os dados.

228
00:11:01,692 --> 00:11:05,043
‫Portanto, ao pensar sobre nosso modelo de dados, essa maneira de

229
00:11:05,043 --> 00:11:08,378
‫organizar os dados funciona, é claro, em ambas as formas.

230
00:11:08,378 --> 00:11:12,570
‫Agora, como realmente decidimos se devemos normalizar

231
00:11:12,570 --> 00:11:15,330
‫ou desnormalizar os dados?

232
00:11:15,330 --> 00:11:18,033
‫Bem, isso é exatamente o que vamos aprender a seguir.

233
00:11:19,690 --> 00:11:22,974
‫Então, quando temos dois conjuntos de dados relacionados; temos que decidir

234
00:11:22,974 --> 00:11:26,180
‫se vamos incorporar os conjuntos de dados ou se vamos

235
00:11:26,180 --> 00:11:27,693
‫mantê-los separados e referenciá-los

236
00:11:27,693 --> 00:11:30,400
‫de um conjunto de dados para o outro.

237
00:11:30,400 --> 00:11:32,730
‫E eu meio que desenvolvi essa

238
00:11:32,730 --> 00:11:36,070
‫estrutura de decisão que vou mostrar onde usamos três critérios

239
00:11:36,070 --> 00:11:37,770
‫para tomar essa decisão.

240
00:11:37,770 --> 00:11:40,450
‫Primeiro, examinamos o tipo de relacionamento que

241
00:11:40,450 --> 00:11:42,800
‫existe entre os conjuntos de dados.

242
00:11:42,800 --> 00:11:45,856
‫Em segundo lugar, tentamos determinar o padrão de

243
00:11:45,856 --> 00:11:50,150
‫acesso aos dados do conjunto de dados que queremos incorporar ou fazer referência.

244
00:11:50,150 --> 00:11:53,320
‫E isso significa apenas analisar a frequência com que os dados são

245
00:11:53,320 --> 00:11:55,282
‫lidos e gravados nesse conjunto de dados.

246
00:11:55,282 --> 00:11:59,025
‫Em seguida, também examinamos algo que chamo de proximidade de dados.

247
00:11:59,025 --> 00:12:02,940
‫E proximidade de dados é um termo que eu acabei de inventar,

248
00:12:02,940 --> 00:12:06,870
‫mas o que significa é o quanto os dados estão realmente relacionados e

249
00:12:06,870 --> 00:12:10,109
‫como queremos consultar os dados do banco de dados.

250
00:12:10,109 --> 00:12:11,850
‫E isso fará mais sentido

251
00:12:11,850 --> 00:12:14,180
‫quando falarmos sobre isso em um momento.

252
00:12:14,180 --> 00:12:17,330
‫Agora, para realmente tomar a decisão; precisamos combinar

253
00:12:17,330 --> 00:12:19,350
‫todos esses três critérios

254
00:12:19,350 --> 00:12:21,792
‫e não apenas usar um deles isoladamente.

255
00:12:21,792 --> 00:12:25,230
‫Então, por exemplo; só porque o critério número um diz

256
00:12:25,230 --> 00:12:28,380
‫para incorporá-lo, não significa que não precisamos olhar

257
00:12:28,380 --> 00:12:30,425
‫para os outros dois critérios.

258
00:12:30,425 --> 00:12:34,124
‫Tudo bem e vamos começar com o tipo de relacionamento.

259
00:12:34,124 --> 00:12:37,968
‫Normalmente, quando temos um relacionamento um para poucos, sempre incorporaremos

260
00:12:37,968 --> 00:12:40,700
‫o conjunto de dados relacionado ao conjunto

261
00:12:40,700 --> 00:12:43,430
‫de dados principal, como aprendemos no

262
00:12:43,430 --> 00:12:45,860
‫último slide. Direito.

263
00:12:45,860 --> 00:12:49,110
‫Agora em um relacionamento de um para muitos; as coisas estão

264
00:12:49,110 --> 00:12:52,880
‫um pouco mais confusas, então não há problema em incorporar ou fazer referência.

265
00:12:52,880 --> 00:12:55,140
‫Nesse caso, teremos de decidir de acordo

266
00:12:55,140 --> 00:12:57,304
‫com os outros dois critérios.

267
00:12:57,304 --> 00:12:59,825
‫Por outro lado, em uma relação de

268
00:12:59,825 --> 00:13:03,894
‫um para uma tonelada ou de muitos para muitos, geralmente sempre

269
00:13:03,894 --> 00:13:06,811
‫referenciamos os dados. Isso porque, se realmente

270
00:13:06,811 --> 00:13:10,004
‫incorporássemos neste caso, poderíamos criar rapidamente um documento muito grande.

271
00:13:10,004 --> 00:13:14,902
‫Mesmo ultrapassando potencialmente o máximo de 16 megabytes.

272
00:13:14,902 --> 00:13:18,214
‫E então a solução para isso é referenciar

273
00:13:18,214 --> 00:13:22,090
‫ou normalizar os dados. E como um exemplo rápido;

274
00:13:22,090 --> 00:13:24,142
‫digamos que em nosso exemplo de banco

275
00:13:24,142 --> 00:13:27,830
‫de dados de filmes, temos cerca de 100 imagens associadas a cada filme.

276
00:13:27,830 --> 00:13:30,874
‫Portanto, poderíamos dizer que é um relacionamento de

277
00:13:30,874 --> 00:13:34,230
‫um para muitos, mas vamos incorporar o conjunto de dados

278
00:13:34,230 --> 00:13:37,523
‫ou devemos referenciá-los aqui. Bem, nós realmente não sabemos.

279
00:13:37,523 --> 00:13:40,571
‫Então, vamos dar uma olhada nos outros dois critérios.

280
00:13:40,571 --> 00:13:44,420
‫Portanto, o segundo é sobre padrões de acesso a dados, onde

281
00:13:44,420 --> 00:13:46,290
‫é apenas uma descrição

282
00:13:46,290 --> 00:13:48,242
‫sofisticada para avaliar se um

283
00:13:48,242 --> 00:13:51,559
‫determinado conjunto de dados é principalmente escrito ou lido.

284
00:13:51,559 --> 00:13:55,760
‫Portanto, se o conjunto de dados sobre o qual estamos decidindo for quase

285
00:13:55,760 --> 00:13:58,179
‫todo lido e os dados não

286
00:13:58,179 --> 00:14:01,620
‫forem muito atualizados, provavelmente devemos incorporar esse conjunto de dados.

287
00:14:01,620 --> 00:14:04,690
‫Portanto, uma alta proporção de leitura / gravação significa apenas que

288
00:14:04,690 --> 00:14:07,100
‫há muito mais leitura do que escrita.

289
00:14:07,100 --> 00:14:11,100
‫E, novamente, um conjunto de dados como esse é um bom candidato

290
00:14:11,100 --> 00:14:11,983
‫para incorporação.

291
00:14:12,830 --> 00:14:15,980
‫A razão para isso é que, com a incorporação, precisamos apenas de

292
00:14:15,980 --> 00:14:18,379
‫uma viagem ao banco de dados por consulta.

293
00:14:18,379 --> 00:14:22,197
‫Já para referenciar, precisamos de duas viagens. Direito.

294
00:14:22,197 --> 00:14:25,660
‫Portanto, se incorporarmos dados que são muito lidos; em

295
00:14:25,660 --> 00:14:28,383
‫cada consulta, economizamos uma viagem ao

296
00:14:28,383 --> 00:14:32,147
‫banco de dados, tornando todo o processo muito mais eficiente.

297
00:14:32,147 --> 00:14:35,260
‫Portanto, acho que nosso exemplo de imagem de

298
00:14:35,260 --> 00:14:38,320
‫filme seria um bom candidato para incorporação.

299
00:14:38,320 --> 00:14:41,543
‫Porque uma vez que as 100 imagens são salvas

300
00:14:41,543 --> 00:14:43,920
‫no banco de dados, elas não são

301
00:14:43,920 --> 00:14:46,930
‫mais atualizadas porque não há realmente nada para atualizar

302
00:14:46,930 --> 00:14:50,057
‫sobre uma imagem. Certo, então é

303
00:14:50,057 --> 00:14:52,563
‫tudo sobre leitura e, portanto, com

304
00:14:52,563 --> 00:14:55,501
‫base nesses critérios, incorporaríamos os documentos com imagens.

305
00:14:55,501 --> 00:14:59,092
‫Por outro lado, se nossos dados são

306
00:14:59,092 --> 00:15:03,118
‫muito atualizados, devemos considerar referenciar ou normalizar os dados.

307
00:15:03,118 --> 00:15:06,700
‫Isso porque dá mais trabalho para o mecanismo de banco de

308
00:15:06,700 --> 00:15:08,870
‫dados atualizar e incorporar um

309
00:15:08,870 --> 00:15:11,600
‫documento do que um documento autônomo mais simples.

310
00:15:11,600 --> 00:15:13,980
‫E já que nosso principal objetivo é o desempenho;

311
00:15:13,980 --> 00:15:15,917
‫apenas normalizamos o conjunto de dados.

312
00:15:15,917 --> 00:15:19,653
‫Em nosso exemplo, digamos que cada filme tenha muitas análises e

313
00:15:19,653 --> 00:15:23,284
‫cada análise pode ser marcada como útil pelo usuário.

314
00:15:23,284 --> 00:15:27,560
‫Portanto, cada vez que alguém clica nessa avaliação, nosso aplicativo

315
00:15:27,560 --> 00:15:29,780
‫é útil. Precisamos

316
00:15:29,780 --> 00:15:31,740
‫atualizar o documento correspondente.

317
00:15:31,740 --> 00:15:35,030
‫E isso significa que os dados podem mudar o

318
00:15:35,030 --> 00:15:38,520
‫tempo todo e, portanto, esse é um ótimo candidato para normalização.

319
00:15:38,520 --> 00:15:41,420
‫Mais uma vez, porque não queremos consultar os filmes

320
00:15:41,420 --> 00:15:45,190
‫o tempo todo se tudo o que realmente queremos atualizar são

321
00:15:45,190 --> 00:15:47,230
‫as avaliações, marcando-as como úteis.

322
00:15:47,230 --> 00:15:49,464
‫Ok, isso faz sentido?

323
00:15:49,464 --> 00:15:53,500
‫E, finalmente, o último critério eu chamo de proximidade de dados;

324
00:15:53,500 --> 00:15:56,320
‫que é como uma medida de quanto os

325
00:15:56,320 --> 00:15:59,469
‫dados estão relacionados. Portanto, se os

326
00:15:59,469 --> 00:16:02,890
‫dois conjuntos de dados realmente pertencem intrinsecamente um ao

327
00:16:02,890 --> 00:16:05,880
‫outro, provavelmente devem ser incorporados um ao outro.

328
00:16:05,880 --> 00:16:10,440
‫Em nosso exemplo; todos os usuários podem ter muitos endereços de e-mail

329
00:16:10,440 --> 00:16:13,780
‫em sua conta e, como estão intrinsecamente conectados

330
00:16:13,780 --> 00:16:17,190
‫ao usuário, não há dúvidas de que os

331
00:16:17,190 --> 00:16:19,920
‫e-mails devem ser incorporados ao documento.

332
00:16:19,920 --> 00:16:23,830
‫Agora, se frequentemente precisamos consultar os dois conjuntos de dados sozinhos,

333
00:16:23,830 --> 00:16:26,388
‫esse é um bom motivo para

334
00:16:26,388 --> 00:16:29,696
‫normalizar os dados em dois conjuntos de dados separados.

335
00:16:29,696 --> 00:16:32,790
‫Mesmo se eles estiverem intimamente relacionados.

336
00:16:32,790 --> 00:16:35,227
‫Então imagine que em nosso aplicativo

337
00:16:35,227 --> 00:16:40,227
‫temos um questionário onde os usuários têm que identificar um filme baseado em imagens.

338
00:16:40,440 --> 00:16:43,080
‫Isso significa que vamos consultar muitas imagens por

339
00:16:43,080 --> 00:16:44,180
‫conta própria.

340
00:16:44,180 --> 00:16:47,756
‫Portanto, sem necessariamente consultar os próprios filmes.

341
00:16:47,756 --> 00:16:50,640
‫E assim, se aplicarmos este terceiro critério; chegamos

342
00:16:50,640 --> 00:16:54,137
‫à conclusão de que devemos realmente normalizar o conjunto de

343
00:16:54,137 --> 00:16:56,759
‫dados da imagem. Tudo bem.

344
00:16:56,759 --> 00:17:00,770
‫Porque, novamente, se implementarmos essa funcionalidade de questionário; as

345
00:17:00,770 --> 00:17:04,057
‫imagens serão consultadas sozinhas o tempo todo.

346
00:17:04,057 --> 00:17:07,422
‫Então, tudo isso mostra que devemos realmente olhar

347
00:17:07,422 --> 00:17:09,850
‫todos os três critérios juntos,

348
00:17:09,850 --> 00:17:12,700
‫em vez de apenas um deles isoladamente.

349
00:17:12,700 --> 00:17:15,841
‫Porque isso pode levar a decisões menos ideais.

350
00:17:15,841 --> 00:17:18,908
‫E eu digo menos ideal em vez de

351
00:17:18,908 --> 00:17:21,766
‫errado porque eles não são maneiras

352
00:17:21,766 --> 00:17:25,262
‫completamente certas ou completamente erradas de modelar nossos dados.

353
00:17:25,262 --> 00:17:28,970
‫Não existem regras rígidas; são apenas diretrizes que você pode

354
00:17:28,970 --> 00:17:31,380
‫seguir para encontrar a maneira

355
00:17:31,380 --> 00:17:33,860
‫provavelmente mais correta de estruturar seus dados.

356
00:17:33,860 --> 00:17:37,077
‫Mas, novamente, é difícil estar realmente errado.

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

358
00:17:39,740 --> 00:17:43,110
‫Agora, digamos que optamos por normalizar nossos conjuntos

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

360
00:17:44,270 --> 00:17:46,653
‫Em outras palavras, para fazer referência aos dados.

361
00:17:46,653 --> 00:17:49,380
‫Depois disso, ainda temos que

362
00:17:49,380 --> 00:17:52,840
‫escolher entre três tipos diferentes de referência.

363
00:17:52,840 --> 00:17:55,460
‫Referência de criança, referência de pai

364
00:17:55,460 --> 00:17:57,540
‫e referência bidirecional.

365
00:17:57,540 --> 00:18:00,767
‫Portanto, o primeiro tipo é a referência à criança.

366
00:18:00,767 --> 00:18:04,440
‫Qual é o tipo de referência que eu realmente mostrei antes.

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

368
00:18:05,470 --> 00:18:07,850
‫E não vamos pegar o exemplo de registro de

369
00:18:07,850 --> 00:18:10,128
‫erros que mencionei anteriormente. Onde poderíamos

370
00:18:10,128 --> 00:18:13,021
‫potencialmente ter milhões de documentos bloqueados.

371
00:18:13,021 --> 00:18:17,300
‫Portanto, na referência de crianças; basicamente mantemos referências aos

372
00:18:17,300 --> 00:18:20,460
‫documentos-filho relacionados em um documento-pai.

373
00:18:20,460 --> 00:18:22,941
‫E geralmente são armazenados em uma matriz.

374
00:18:22,941 --> 00:18:25,735
‫Então, você vê que cada log tem um

375
00:18:25,735 --> 00:18:29,040
‫ID e, no documento do aplicativo, há aquele array com

376
00:18:29,040 --> 00:18:31,358
‫todos esses IDs. Direito?

377
00:18:31,358 --> 00:18:34,400
‫No entanto, o problema aqui é que

378
00:18:34,400 --> 00:18:39,320
‫essa matriz de IDs pode se tornar muito grande se houver muitos filhos.

379
00:18:39,320 --> 00:18:42,230
‫E este é um anti-padrão no MongoDB.

380
00:18:42,230 --> 00:18:45,156
‫Portanto, algo que devemos evitar a todo custo.

381
00:18:45,156 --> 00:18:47,660
‫Além disso, a referência a crianças

382
00:18:47,660 --> 00:18:51,410
‫faz com que pais e filhos estejam intimamente ligados.

383
00:18:51,410 --> 00:18:54,840
‫O que nem sempre é ideal. Mas é exatamente por

384
00:18:54,840 --> 00:18:57,020
‫isso que temos referências aos pais.

385
00:18:57,020 --> 00:19:00,300
‫Portanto, na referência do pai; na verdade,

386
00:19:00,300 --> 00:19:01,870
‫funciona ao contrário.

387
00:19:01,870 --> 00:19:05,570
‫Portanto, aqui em cada documento filho, mantemos uma

388
00:19:05,570 --> 00:19:07,430
‫referência ao elemento pai.

389
00:19:07,430 --> 00:19:10,267
‫Portanto, o nome pai faz referência.

390
00:19:10,267 --> 00:19:13,890
‫Neste exemplo, o ID do aplicativo é 23 e, portanto,

391
00:19:13,890 --> 00:19:16,640
‫em cada log há o campo do aplicativo

392
00:19:16,640 --> 00:19:18,990
‫com o ID 23 nele.

393
00:19:18,990 --> 00:19:21,660
‫Para que a criança sempre conheça seu pai.

394
00:19:21,660 --> 00:19:24,920
‫E então, neste caso, o pai realmente não sabe nada

395
00:19:24,920 --> 00:19:26,080
‫sobre os filhos.

396
00:19:26,080 --> 00:19:28,768
‫Não quem eles são e não quantos são.

397
00:19:28,768 --> 00:19:32,890
‫Então, eles são muito mais isolados e autônomos.

398
00:19:32,890 --> 00:19:35,326
‫Nisso, às vezes pode ser benéfico.

399
00:19:35,326 --> 00:19:38,880
‫Então, qual desses dois tipos é realmente melhor para

400
00:19:38,880 --> 00:19:40,527
‫esse relacionamento de dados.

401
00:19:40,527 --> 00:19:42,820
‫E lembre-se de como eu disse que pode

402
00:19:42,820 --> 00:19:45,860
‫haver milhões de registros e, portanto, vamos supor que haja

403
00:19:45,860 --> 00:19:47,652
‫dois milhões de documentos registrados.

404
00:19:47,652 --> 00:19:51,340
‫Em um caso de referência de criança, isso significaria que há

405
00:19:51,340 --> 00:19:53,209
‫dois milhões de referências

406
00:19:53,209 --> 00:19:55,091
‫de ID no documento do aplicativo.

407
00:19:55,091 --> 00:19:58,300
‫Direito? Agora lembre-se também de como eu

408
00:19:58,300 --> 00:20:00,545
‫disse que há um limite de 16 megabytes para documentos.

409
00:20:00,545 --> 00:20:04,302
‫Portanto, se continuarmos adicionando e adicionando esses IDs filhos à

410
00:20:04,302 --> 00:20:06,716
‫matriz do pai; então, atingiríamos rapidamente

411
00:20:06,716 --> 00:20:09,575
‫o limite de 16 megabytes que cada

412
00:20:09,575 --> 00:20:11,772
‫documento Bson pode conter.

413
00:20:11,772 --> 00:20:14,702
‫Simplesmente porque essa matriz vai crescer muito.

414
00:20:14,702 --> 00:20:17,210
‫Então isso realmente não vai funcionar.

415
00:20:17,210 --> 00:20:18,510
‫É isso?

416
00:20:18,510 --> 00:20:20,590
‫Por outro lado, com o pai

417
00:20:20,590 --> 00:20:22,990
‫referindo-se a esse problema não vai acontecer.

418
00:20:22,990 --> 00:20:25,570
‫Teremos simplesmente dois milhões de documentos

419
00:20:25,570 --> 00:20:30,540
‫bloqueados como antes, mas cada um deles contém a ID de seu pai.

420
00:20:30,540 --> 00:20:33,098
‫Mas não há matriz que

421
00:20:33,098 --> 00:20:35,740
‫cresça indefinidamente e, portanto, a referência

422
00:20:35,740 --> 00:20:38,443
‫do pai seria a melhor solução aqui.

423
00:20:39,380 --> 00:20:41,901
‫Portanto, a conclusão de tudo isso é que,

424
00:20:41,901 --> 00:20:44,385
‫em geral, a referência à criança é mais

425
00:20:44,385 --> 00:20:48,008
‫bem usada para alguns relacionamentos. Onde sabemos de antemão

426
00:20:48,008 --> 00:20:51,118
‫que a variedade de documentos filhos não aumentará tanto.

427
00:20:51,118 --> 00:20:54,573
‫Por outro lado, a referência aos pais é melhor usada

428
00:20:54,573 --> 00:20:58,690
‫para relacionamentos de um para muitos e de um para uma tonelada

429
00:20:58,690 --> 00:21:00,927
‫como este. OK?

430
00:21:00,927 --> 00:21:04,610
‫Portanto, sempre tenha em mente que um dos

431
00:21:04,610 --> 00:21:07,920
‫princípios mais importantes da modelagem de dados

432
00:21:07,920 --> 00:21:11,900
‫MongoDB é que o array nunca deve crescer indefinidamente.

433
00:21:11,900 --> 00:21:15,420
‫Para nunca ultrapassar esse limite de 16 megabytes.

434
00:21:15,420 --> 00:21:18,170
‫Também não queremos enviar aos nossos usuários um array

435
00:21:18,170 --> 00:21:20,730
‫com milhares de IDs cada vez que eles solicitarem

436
00:21:20,730 --> 00:21:24,340
‫um conjunto de dados pai. OK?

437
00:21:24,340 --> 00:21:26,900
‫Então, essa lógica fez sentido para você?

438
00:21:26,900 --> 00:21:29,660
‫Em seguida, vamos passar para o terceiro tipo de

439
00:21:29,660 --> 00:21:31,870
‫referência, que é a referência bidirecional.

440
00:21:31,870 --> 00:21:34,395
‫E desta vez com o exemplo do filme

441
00:21:34,395 --> 00:21:36,380
‫e ator que mostrei quando falamos sobre

442
00:21:36,380 --> 00:21:39,364
‫muitos para muitos relacionamentos. Lembre-se disso?

443
00:21:39,364 --> 00:21:42,229
‫Então, novamente, cada filme tem muitos atores e

444
00:21:42,229 --> 00:21:44,880
‫cada ator atua em muitos filmes.

445
00:21:44,880 --> 00:21:48,464
‫E esse é um relacionamento típico de muitos para muitos.

446
00:21:48,464 --> 00:21:52,100
‫E geralmente usamos essa referência bidirecional para

447
00:21:52,100 --> 00:21:55,346
‫projetar muitos relacionamentos. E funciona

448
00:21:55,346 --> 00:21:59,370
‫assim; em cada filme, manteremos referências a todos os

449
00:21:59,370 --> 00:22:03,980
‫atores que protagonizam aquele filme. É um pouco como na referência infantil.

450
00:22:03,980 --> 00:22:07,000
‫No entanto, e ao mesmo tempo, em cada ator

451
00:22:07,000 --> 00:22:09,570
‫também mantemos referências a todos os filmes

452
00:22:09,570 --> 00:22:11,660
‫em que o ator atuou.

453
00:22:11,660 --> 00:22:15,120
‫Assim, filmes e atores estão conectados em ambas as direções.

454
00:22:15,120 --> 00:22:17,900
‫Portanto, o nome referenciamento bidirecional.

455
00:22:17,900 --> 00:22:19,950
‫E isso torna muito

456
00:22:19,950 --> 00:22:23,290
‫fácil pesquisar filmes e atores de forma totalmente independente.

457
00:22:23,290 --> 00:22:25,910
‫Ao mesmo tempo que facilita a localização dos

458
00:22:25,910 --> 00:22:29,029
‫atores associados a cada filme e dos filmes associados

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

460
00:22:31,623 --> 00:22:32,560
‫(respire fundo)

461
00:22:32,560 --> 00:22:34,747
‫Esta foi uma palestra bastante longa, de fato.

462
00:22:34,747 --> 00:22:38,030
‫Com muitos novos conceitos, princípios e

463
00:22:38,030 --> 00:22:40,220
‫diretrizes para lembrar.

464
00:22:40,220 --> 00:22:43,460
‫Então, para ajudá-lo com isso; aqui está um breve

465
00:22:43,460 --> 00:22:46,650
‫resumo e algumas diretrizes mais gerais que você

466
00:22:46,650 --> 00:22:48,423
‫pode consultar quando precisar.

467
00:22:49,260 --> 00:22:52,753
‫Portanto, o princípio mais importante é: estruturar seus dados

468
00:22:52,753 --> 00:22:56,120
‫para corresponder às formas como seu aplicativo consulta e

469
00:22:56,120 --> 00:22:57,436
‫atualiza os dados.

470
00:22:57,436 --> 00:23:01,400
‫Ou em outras palavras: identifique as perguntas que surgem dos casos de

471
00:23:01,400 --> 00:23:03,784
‫uso do seu aplicativo primeiro e, em

472
00:23:03,784 --> 00:23:06,634
‫seguida, modele seus dados para que as perguntas possam

473
00:23:06,634 --> 00:23:08,995
‫ser respondidas da maneira mais eficiente.

474
00:23:08,995 --> 00:23:12,610
‫Por exemplo; quando preciso consultar filmes e atores sempre

475
00:23:12,610 --> 00:23:16,130
‫juntos ou há cenários em que só consulto

476
00:23:16,130 --> 00:23:18,041
‫filmes ou apenas atores.

477
00:23:18,041 --> 00:23:20,528
‫É nesse tipo de pergunta que o

478
00:23:20,528 --> 00:23:22,930
‫seu modelo de dados será baseado.

479
00:23:22,930 --> 00:23:26,730
‫Em geral, sempre dê preferência à incorporação, a menos que haja um

480
00:23:26,730 --> 00:23:28,440
‫bom motivo para não incorporar.

481
00:23:28,440 --> 00:23:32,513
‫Especialmente em um para alguns e um para muitos relacionamentos.

482
00:23:33,370 --> 00:23:37,713
‫Em seguida, um relacionamento de um para uma tonelada ou de muitos para muitos

483
00:23:37,713 --> 00:23:41,543
‫é geralmente um bom motivo para fazer referência em vez de incorporar.

484
00:23:41,543 --> 00:23:45,734
‫Além disso, favorece a referência quando os dados são atualizados

485
00:23:45,734 --> 00:23:50,717
‫muito e se você precisa acessar frequentemente um conjunto de dados por conta própria.

486
00:23:50,717 --> 00:23:55,340
‫Use a incorporação quando os dados são mais lidos, mas raramente atualizados, e quando

487
00:23:55,340 --> 00:23:58,469
‫dois conjuntos de dados pertencem intrinsecamente um ao outro.

488
00:23:58,469 --> 00:24:02,840
‫Não permita que os arrays cresçam indefinidamente.

489
00:24:02,840 --> 00:24:05,982
‫Portanto, se você deseja normalizar; use a referência de

490
00:24:05,982 --> 00:24:09,680
‫filho para um para muitos relacionamentos e a referência de pai

491
00:24:09,680 --> 00:24:11,856
‫para um para muitos relacionamentos.

492
00:24:11,856 --> 00:24:15,160
‫E, finalmente, use a referência bidirecional para

493
00:24:15,160 --> 00:24:17,520
‫muitos para muitos relacionamentos.

494
00:24:17,520 --> 00:24:18,720
‫Tudo bem?

495
00:24:18,720 --> 00:24:21,202
‫E isso resume tudo.

496
00:24:21,202 --> 00:24:23,970
‫Na verdade, eu recomendo que você assista a

497
00:24:23,970 --> 00:24:27,144
‫este vídeo duas vezes, se puder, apenas por causa

498
00:24:27,144 --> 00:24:30,091
‫da importância deste material. Tudo bem?

499
00:24:30,091 --> 00:24:33,363
‫Enfim, até o próximo vídeo.