1
00:00:01,180 --> 00:00:02,990
‫Narratore: Uno dei passaggi più

2
00:00:02,990 --> 00:00:06,250
‫importanti nella creazione di app ad alta intensità di dati

3
00:00:06,250 --> 00:00:08,700
‫è modellare effettivamente tutti questi dati in MongoDB.

4
00:00:08,700 --> 00:00:12,300
‫Ed è di questo che parleremo in questa lezione.

5
00:00:12,300 --> 00:00:14,710
‫Quindi è davvero fondamentale seguirlo

6
00:00:14,710 --> 00:00:19,710
‫anche all'inizio è molto da accettare. Va bene.

7
00:00:19,810 --> 00:00:22,013
‫Comunque, ora iniziamo.

8
00:00:23,530 --> 00:00:27,530
‫Ora, la modellazione dei dati è probabilmente un concetto molto nuovo per te.

9
00:00:27,530 --> 00:00:28,920
‫Quindi, prima di

10
00:00:28,920 --> 00:00:32,070
‫iniziare; chiariamo di cosa parleremo in realtà.

11
00:00:32,070 --> 00:00:35,656
‫Quindi, la modellazione dei dati è il processo di prendere dati

12
00:00:35,656 --> 00:00:38,770
‫non strutturati generati da uno scenario del mondo reale

13
00:00:38,770 --> 00:00:42,090
‫e quindi strutturarli in un modello di dati logico

14
00:00:42,090 --> 00:00:43,410
‫in un database.

15
00:00:43,410 --> 00:00:46,300
‫E lo facciamo secondo una serie

16
00:00:46,300 --> 00:00:49,330
‫di criteri che impareremo in questo video.

17
00:00:49,330 --> 00:00:51,980
‫Per esempio; diciamo che vogliamo progettare un modello

18
00:00:51,980 --> 00:00:54,120
‫di dati del negozio online.

19
00:00:54,120 --> 00:00:57,040
‫Inizialmente ci saranno una tonnellata di dati non strutturati di cui

20
00:00:57,040 --> 00:00:58,130
‫sappiamo di aver bisogno.

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

22
00:00:58,980 --> 00:01:00,900
‫Cose come prodotti, categorie,

23
00:01:00,900 --> 00:01:03,875
‫ordini dei clienti, carrelli della spesa, fornitori.

24
00:01:03,875 --> 00:01:06,300
‫E così via e così via.

25
00:01:06,300 --> 00:01:09,240
‫Il nostro obiettivo con la modellazione dei dati è quindi

26
00:01:09,240 --> 00:01:11,450
‫strutturare questi dati in modo logico.

27
00:01:11,450 --> 00:01:14,090
‫Riflettendo le relazioni del mondo reale che

28
00:01:14,090 --> 00:01:16,920
‫esistono tra alcuni di questi set di dati.

29
00:01:16,920 --> 00:01:19,670
‫Un po' come puoi vedere in questo esempio.

30
00:01:19,670 --> 00:01:23,110
‫E questa è ovviamente solo una specie di situazione immaginaria,

31
00:01:23,110 --> 00:01:24,320
‫ma rende l'idea.

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

33
00:01:25,600 --> 00:01:28,940
‫Ora, molti sviluppatori di backend affermano che la modellazione dei dati

34
00:01:28,940 --> 00:01:30,930
‫è dove dobbiamo pensare di più.

35
00:01:30,930 --> 00:01:33,670
‫Questa è la parte più impegnativa della

36
00:01:33,670 --> 00:01:35,310
‫creazione di un'intera applicazione.

37
00:01:35,310 --> 00:01:38,100
‫Perché in realtà non è sempre semplice.

38
00:01:38,100 --> 00:01:41,070
‫E a volte semplicemente non ci sono risposte giuste.

39
00:01:41,070 --> 00:01:45,500
‫Quindi non solo un unico modo corretto di strutturare i dati.

40
00:01:45,500 --> 00:01:48,420
‫Ma comunque farò del mio meglio per definire il processo

41
00:01:48,420 --> 00:01:49,510
‫in questo video.

42
00:01:49,510 --> 00:01:52,367
‫E per questo faremo quattro passi.

43
00:01:52,367 --> 00:01:56,200
‫Quindi nel primo passaggio; abbiamo imparato come identificare diversi

44
00:01:56,200 --> 00:01:59,340
‫tipi di relazioni tra i dati.

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

46
00:02:00,360 --> 00:02:03,019
‫capiremo la differenza tra

47
00:02:03,019 --> 00:02:07,163
‫referenziazione o normalizzazione e incorporamento o denormalizzazione.

48
00:02:07,163 --> 00:02:09,030
‫Nel passaggio successivo e

49
00:02:09,030 --> 00:02:11,660
‫più importante; Ti mostrerò la mia struttura per

50
00:02:11,660 --> 00:02:13,560
‫decidere se dobbiamo incorporare documenti

51
00:02:13,560 --> 00:02:15,750
‫o fare riferimento ad altri documenti

52
00:02:15,750 --> 00:02:18,690
‫in base a un paio di fattori diversi.

53
00:02:18,690 --> 00:02:20,810
‫Inoltre, dobbiamo parlare rapidamente di

54
00:02:20,810 --> 00:02:22,680
‫diversi tipi di referenziazione.

55
00:02:22,680 --> 00:02:25,920
‫Perché questo è importante se questo è il tipo di

56
00:02:25,920 --> 00:02:28,220
‫design che scegliamo per i nostri dati.

57
00:02:28,220 --> 00:02:32,290
‫Quindi questa sarà in effetti una lezione abbastanza teorica.

58
00:02:32,290 --> 00:02:35,940
‫Ma anche assolutamente essenziale per i tuoi progressi

59
00:02:35,940 --> 00:02:37,660
‫come sviluppatore back-end.

60
00:02:37,660 --> 00:02:41,553
‫Perché il modo in cui progettiamo i dati e il modo in

61
00:02:41,553 --> 00:02:45,180
‫cui modelliamo i nostri dati può creare o distruggere l'intera applicazione.

62
00:02:45,180 --> 00:02:47,950
‫E ci saranno molti esempi lungo la strada per

63
00:02:47,950 --> 00:02:49,510
‫rendere questo processo più semplice.

64
00:02:49,510 --> 00:02:50,343
‫Va bene.

65
00:02:51,320 --> 00:02:53,440
‫E la prima cosa di

66
00:02:53,440 --> 00:02:55,780
‫cui parleremo sono i diversi tipi di

67
00:02:55,780 --> 00:02:58,210
‫relazioni che possono esistere tra i dati.

68
00:02:58,210 --> 00:03:00,780
‫Quindi ci sono tre grandi tipi di relazioni.

69
00:03:00,780 --> 00:03:05,150
‫Uno a uno, uno a molti e molti a molti.

70
00:03:05,150 --> 00:03:06,990
‫E userò un'applicazione per

71
00:03:06,990 --> 00:03:08,890
‫film come esempio in questa diapositiva.

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

73
00:03:10,000 --> 00:03:12,440
‫Quindi, prima una relazione uno a uno

74
00:03:12,440 --> 00:03:14,140
‫tra i dati è

75
00:03:14,140 --> 00:03:17,370
‫fondamentalmente quando un campo può avere un solo valore.

76
00:03:17,370 --> 00:03:21,550
‫Quindi nel nostro esempio di applicazione per film; un film ha sempre

77
00:03:21,550 --> 00:03:22,990
‫e solo un nome.

78
00:03:22,990 --> 00:03:24,910
‫E quindi questo è un

79
00:03:24,910 --> 00:03:27,160
‫semplice esempio di relazione uno a uno.

80
00:03:27,160 --> 00:03:29,690
‫Ma queste relazioni non sono poi così importanti in

81
00:03:29,690 --> 00:03:31,363
‫termini di modellazione dei dati.

82
00:03:32,330 --> 00:03:34,430
‫Ora le relazioni più

83
00:03:34,430 --> 00:03:37,210
‫importanti sono le relazioni uno a molti.

84
00:03:37,210 --> 00:03:39,770
‫E sono così importanti che in MongoDB

85
00:03:39,770 --> 00:03:42,510
‫distinguiamo effettivamente tra tre tipi di relazioni

86
00:03:42,510 --> 00:03:44,540
‫da uno a molti.

87
00:03:44,540 --> 00:03:49,540
‫Uno a pochi, uno a molti e uno a una tonnellata o a un milione

88
00:03:49,910 --> 00:03:53,230
‫o qualcosa del genere. Quindi la differenza qui si

89
00:03:53,230 --> 00:03:56,893
‫basa sulla quantità relativa dei molti. Va bene.

90
00:03:57,840 --> 00:04:00,969
‫Quindi un esempio per una relazione uno a

91
00:04:00,969 --> 00:04:05,967
‫pochi è che un film può vincere molti premi, ma in realtà solo pochi.

92
00:04:05,967 --> 00:04:09,630
‫Quindi il film non vincerà mille premi, ma

93
00:04:09,630 --> 00:04:11,220
‫può vincerne alcuni.

94
00:04:11,220 --> 00:04:14,930
‫E quindi questo è un tipico rapporto da uno a pochi.

95
00:04:14,930 --> 00:04:18,710
‫Quindi vedi che in generale una relazione uno a

96
00:04:18,710 --> 00:04:23,210
‫molti significa che un documento può essere correlato a molti altri documenti.

97
00:04:23,210 --> 00:04:26,680
‫Ora questo potrebbe sembrare un po' astratto senza i dati JSON, ma in

98
00:04:26,680 --> 00:04:28,480
‫realtà è questo lo scopo qui.

99
00:04:28,480 --> 00:04:31,040
‫Voglio solo mostrarti una panoramica

100
00:04:31,040 --> 00:04:33,759
‫concettuale di questi diversi tipi di relazioni.

101
00:04:33,759 --> 00:04:36,872
‫Ad ogni modo, qualsiasi relazione uno a

102
00:04:36,872 --> 00:04:40,600
‫molti un documento può riguardare centinaia o migliaia di

103
00:04:40,600 --> 00:04:42,070
‫altri documenti.

104
00:04:42,070 --> 00:04:44,788
‫Per esempio; un film può avere migliaia di

105
00:04:44,788 --> 00:04:46,710
‫recensioni nella nostra applicazione.

106
00:04:46,710 --> 00:04:49,380
‫E quindi questo non è proprio un rapporto uno a pochi,

107
00:04:49,380 --> 00:04:51,524
‫ma uno a molti. Va bene?

108
00:04:51,524 --> 00:04:55,616
‫E infine abbiamo il rapporto uno a ton.

109
00:04:55,616 --> 00:04:59,720
‫Immagina di voler implementare alcune funzionalità di registrazione

110
00:04:59,720 --> 00:05:03,110
‫nella nostra app. Quindi, in pratica, per sapere

111
00:05:03,110 --> 00:05:04,870
‫esattamente cosa sta succedendo sul nostro server.

112
00:05:04,870 --> 00:05:08,770
‫Questi registri possono quindi crescere facilmente fino a milioni di documenti.

113
00:05:08,770 --> 00:05:11,270
‫E quindi questo è un esempio

114
00:05:11,270 --> 00:05:14,200
‫molto tipico di una relazione da uno a tonnellate.

115
00:05:14,200 --> 00:05:17,100
‫E la differenza tra molti e una tonnellata

116
00:05:17,100 --> 00:05:20,730
‫è ovviamente un po' confusa, ma pensa solo che se qualcosa

117
00:05:20,730 --> 00:05:23,360
‫può crescere quasi all'infinito, allora è sicuramente una

118
00:05:23,360 --> 00:05:25,532
‫relazione uno a una tonnellata.

119
00:05:25,532 --> 00:05:28,763
‫Quindi ancora una volta le relazioni uno a

120
00:05:28,763 --> 00:05:31,650
‫molti sono le più importanti da conoscere.

121
00:05:31,650 --> 00:05:34,050
‫A proposito; nei database

122
00:05:34,050 --> 00:05:37,061
‫relazionali c'è solo uno a molti

123
00:05:37,061 --> 00:05:39,800
‫senza quantificare quanti siano effettivamente.

124
00:05:39,800 --> 00:05:41,800
‫Nei database MongoDB però

125
00:05:41,800 --> 00:05:44,010
‫è una differenza estremamente importante.

126
00:05:44,010 --> 00:05:47,150
‫Perché è uno dei fattori che useremo

127
00:05:47,150 --> 00:05:49,891
‫per decidere se dobbiamo denormalizzare o

128
00:05:49,891 --> 00:05:53,340
‫normalizzare i dati, come imparerai un po' più tardi.

129
00:05:53,340 --> 00:05:57,181
‫Ad ogni modo, il tipo di relazione minore è il molti a

130
00:05:57,181 --> 00:06:00,149
‫molti in cui un film può avere molti attori.

131
00:06:00,149 --> 00:06:04,876
‫Ma allo stesso tempo un attore può recitare in molti film.

132
00:06:04,876 --> 00:06:07,910
‫E quindi qui la relazione va sostanzialmente in

133
00:06:07,910 --> 00:06:09,630
‫entrambe le direzioni.

134
00:06:09,630 --> 00:06:11,800
‫Dove prima negli altri tipi era

135
00:06:11,800 --> 00:06:13,939
‫solo in una direzione.

136
00:06:13,939 --> 00:06:17,470
‫Ad esempio, un film può avere molte recensioni, ma una

137
00:06:17,470 --> 00:06:22,450
‫specifica è solo per quel film. Destra.

138
00:06:22,450 --> 00:06:24,560
‫E lo stesso vale per i premi.

139
00:06:24,560 --> 00:06:27,506
‫Quindi un premio specifico come per il miglior

140
00:06:27,506 --> 00:06:30,914
‫attore va a un solo film, non a più film.

141
00:06:30,914 --> 00:06:35,580
‫Ma con i film e gli attori è davvero diverso.

142
00:06:35,580 --> 00:06:39,250
‫Quindi ancora una volta un film ha molti attori,

143
00:06:39,250 --> 00:06:41,920
‫ma un attore interpreta molti film

144
00:06:41,920 --> 00:06:45,020
‫e quindi è una relazione molti a molti.

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

146
00:06:46,170 --> 00:06:49,060
‫Quindi tieni tutto questo a mente mentre andiamo avanti

147
00:06:49,060 --> 00:06:50,063
‫in questa lezione.

148
00:06:51,760 --> 00:06:54,870
‫E probabilmente l'aspetto più importante che dobbiamo imparare

149
00:06:54,870 --> 00:06:57,900
‫sui database MongoDB è fare riferimento e

150
00:06:57,900 --> 00:07:00,340
‫incorporare due set di dati.

151
00:07:00,340 --> 00:07:02,350
‫E in realtà ne abbiamo

152
00:07:02,350 --> 00:07:05,050
‫già parlato un po' prima, ma esaminiamolo

153
00:07:05,050 --> 00:07:07,311
‫qui e approfondiamo anche un po'.

154
00:07:07,311 --> 00:07:09,962
‫Quindi, ogni volta che abbiamo due

155
00:07:09,962 --> 00:07:13,829
‫set di dati correlati, possiamo rappresentare quei dati correlati in

156
00:07:13,829 --> 00:07:18,829
‫una forma di riferimento o normalizzata o in una forma incorporata o denormalizzata.

157
00:07:18,842 --> 00:07:22,190
‫E continuo a usare i due termini correlati insieme

158
00:07:22,190 --> 00:07:24,340
‫come fare riferimento e normalizzare perché

159
00:07:24,340 --> 00:07:26,460
‫li vedrai entrambi usati e

160
00:07:26,460 --> 00:07:29,510
‫quindi è importante che tu li conosca tutti.

161
00:07:29,510 --> 00:07:33,070
‫Ad ogni modo, nel modulo di riferimento manteniamo due set di

162
00:07:33,070 --> 00:07:35,826
‫dati correlati e tutti i documenti separati.

163
00:07:35,826 --> 00:07:39,589
‫Quindi di nuovo tutti i dati sono ben separati,

164
00:07:39,589 --> 00:07:43,275
‫il che è esattamente ciò che significa normalizzato.

165
00:07:43,275 --> 00:07:47,110
‫Quindi, continuando, l'esempio del database del film di prima

166
00:07:47,110 --> 00:07:50,750
‫avremmo un documento del film e un documento

167
00:07:50,750 --> 00:07:54,870
‫dell'attore per ogni attore. Ora come faremmo quindi a stabilire

168
00:07:54,870 --> 00:07:58,710
‫la connessione tra il film e gli attori in modo che in seguito nella

169
00:07:58,710 --> 00:08:02,150
‫nostra app possiamo mostrare quali attori hanno recitato in un particolare film.

170
00:08:02,150 --> 00:08:05,210
‫Perché se sono tutti documenti completamente diversi il film non

171
00:08:05,210 --> 00:08:09,438
‫ha modo di conoscere gli attori. Destra.

172
00:08:09,438 --> 00:08:12,253
‫Bene, è qui che entrano in gioco gli ID.

173
00:08:12,253 --> 00:08:16,460
‫Quindi usiamo gli ID attore per creare riferimenti sul

174
00:08:16,460 --> 00:08:18,020
‫documento del film.

175
00:08:18,020 --> 00:08:20,981
‫Connettere efficacemente i film con gli attori.

176
00:08:20,981 --> 00:08:24,760
‫Quindi vedi che in un documento di film abbiamo un array in

177
00:08:24,760 --> 00:08:27,198
‫cui abbiamo archiviato gli ID di tutti gli

178
00:08:27,198 --> 00:08:30,760
‫attori in modo che quando richiediamo dati su un certo film possiamo

179
00:08:30,760 --> 00:08:34,553
‫facilmente identificare i suoi attori. Ha senso?

180
00:08:34,553 --> 00:08:38,830
‫Ora questo tipo di riferimento è chiamato riferimento figlio perché è il

181
00:08:38,830 --> 00:08:41,480
‫genitore in questo caso il film che fa

182
00:08:41,480 --> 00:08:45,104
‫riferimento ai suoi figli. In questo caso gli attori.

183
00:08:45,104 --> 00:08:48,841
‫Quindi stiamo davvero creando una sorta di gerarchia qui. Destra.

184
00:08:48,841 --> 00:08:51,870
‫Ora c'è anche la referenza dei genitori e

185
00:08:51,870 --> 00:08:54,390
‫ne parleremo un po' più tardi.

186
00:08:54,390 --> 00:08:58,710
‫E tra l'altro nei database relazionali; tutti i dati sono

187
00:08:58,710 --> 00:09:01,958
‫sempre rappresentati in forma normalizzata come questa.

188
00:09:01,958 --> 00:09:05,490
‫Ma in un database senza sequel come

189
00:09:05,490 --> 00:09:09,700
‫MongoDB possiamo denormalizzare i dati in una forma

190
00:09:09,700 --> 00:09:12,450
‫denormalizzata semplicemente incorporando il

191
00:09:12,450 --> 00:09:15,330
‫documento correlato direttamente nel documento principale.

192
00:09:15,330 --> 00:09:18,330
‫Quindi ora abbiamo tutti i dati rilevanti

193
00:09:18,330 --> 00:09:22,060
‫sugli attori direttamente all'interno di un documento principale del film

194
00:09:22,060 --> 00:09:25,700
‫senza la necessità di documenti, raccolte e ID separati.

195
00:09:25,700 --> 00:09:30,088
‫Quindi, ancora una volta, se scegliamo di denormalizzare o incorporare i nostri

196
00:09:30,088 --> 00:09:34,280
‫dati, avremo un documento principale contenente tutti i dati principali e

197
00:09:34,280 --> 00:09:37,197
‫i relativi dati. Va bene.

198
00:09:37,197 --> 00:09:40,340
‫E il risultato è che la nostra applicazione

199
00:09:40,340 --> 00:09:43,330
‫avrà bisogno di meno query al database.

200
00:09:43,330 --> 00:09:45,000
‫Perché possiamo ottenere

201
00:09:45,000 --> 00:09:48,074
‫tutti i dati su film e attori

202
00:09:48,074 --> 00:09:51,650
‫contemporaneamente, il che ovviamente aumenterà le nostre prestazioni.

203
00:09:51,650 --> 00:09:53,840
‫Ora il lato negativo qui è

204
00:09:53,840 --> 00:09:57,530
‫ovviamente che non possiamo davvero interrogare i dati incorporati da soli.

205
00:09:57,530 --> 00:10:00,810
‫Quindi, se questo è un requisito per l'applicazione,

206
00:10:00,810 --> 00:10:03,790
‫dovresti scegliere un design normalizzato e poiché

207
00:10:03,790 --> 00:10:06,280
‫stiamo parlando di pro e contro

208
00:10:06,280 --> 00:10:09,030
‫della forma denormalizzata; facciamo lo stesso

209
00:10:09,030 --> 00:10:11,490
‫con il design normalizzato.

210
00:10:11,490 --> 00:10:13,920
‫E fondamentalmente è l'opposto di quello di

211
00:10:13,920 --> 00:10:15,770
‫cui abbiamo appena parlato.

212
00:10:15,770 --> 00:10:18,319
‫Quindi c'è un miglioramento delle prestazioni

213
00:10:18,319 --> 00:10:22,390
‫quando spesso abbiamo bisogno di interrogare i dati correlati da soli

214
00:10:22,390 --> 00:10:25,740
‫perché possiamo semplicemente interrogare i dati di cui abbiamo

215
00:10:25,740 --> 00:10:28,490
‫bisogno e non sempre film e attori insieme.

216
00:10:28,490 --> 00:10:31,640
‫Ma d'altra parte; quando abbiamo bisogno di interrogare effettivamente

217
00:10:31,640 --> 00:10:33,906
‫film e attori insieme, allora

218
00:10:33,906 --> 00:10:36,396
‫avremo bisogno di molte query al database.

219
00:10:36,396 --> 00:10:40,010
‫Quindi prima la query per il film e poi da lì

220
00:10:40,010 --> 00:10:42,610
‫avremo anche bisogno di una query per l'attore

221
00:10:42,610 --> 00:10:44,989
‫e questo ovviamente funziona per le prestazioni.

222
00:10:44,989 --> 00:10:48,328
‫Quindi, quando si progetta il database; questo è il tipo di cose che

223
00:10:48,328 --> 00:10:50,569
‫devi tenere a mente. Va bene.

224
00:10:50,569 --> 00:10:54,900
‫E ora solo come nota a margine; potremmo ovviamente iniziare il nostro

225
00:10:54,900 --> 00:10:56,994
‫processo di pensiero con dati denormalizzati

226
00:10:56,994 --> 00:10:59,670
‫e poi giungere alla conclusione che è meglio

227
00:10:59,670 --> 00:11:01,692
‫normalizzare effettivamente i dati.

228
00:11:01,692 --> 00:11:05,043
‫Quindi, quando si pensa al nostro modello di dati, questo modo

229
00:11:05,043 --> 00:11:08,378
‫di organizzare i dati funziona ovviamente in entrambi i modi.

230
00:11:08,378 --> 00:11:12,570
‫Ora, come decidiamo effettivamente se dobbiamo normalizzare

231
00:11:12,570 --> 00:11:15,330
‫o denormalizzare i dati?

232
00:11:15,330 --> 00:11:18,033
‫Bene, questo è esattamente ciò che impareremo dopo.

233
00:11:19,690 --> 00:11:22,974
‫Quindi, quando abbiamo due set di dati correlati; dobbiamo decidere

234
00:11:22,974 --> 00:11:26,180
‫se incorporeremo i set di dati o se li terremo

235
00:11:26,180 --> 00:11:27,693
‫separati e li

236
00:11:27,693 --> 00:11:30,400
‫faremo riferimento da un set di dati all'altro.

237
00:11:30,400 --> 00:11:32,730
‫E ho in qualche modo sviluppato

238
00:11:32,730 --> 00:11:36,070
‫questo quadro decisionale che ti mostrerò dove usiamo tre criteri

239
00:11:36,070 --> 00:11:37,770
‫per prendere quella decisione.

240
00:11:37,770 --> 00:11:40,450
‫Per prima cosa esaminiamo il tipo di relazioni

241
00:11:40,450 --> 00:11:42,800
‫esistenti tra i set di dati.

242
00:11:42,800 --> 00:11:45,856
‫In secondo luogo, cerchiamo di determinare il modello di

243
00:11:45,856 --> 00:11:50,150
‫accesso ai dati del set di dati che vogliamo incorporare o fare riferimento.

244
00:11:50,150 --> 00:11:53,320
‫E questo significa solo analizzare la frequenza con cui i dati vengono letti

245
00:11:53,320 --> 00:11:55,282
‫e scritti in quel set di dati.

246
00:11:55,282 --> 00:11:59,025
‫Quindi esaminiamo anche qualcosa che chiamo vicinanza dei dati.

247
00:11:59,025 --> 00:12:02,940
‫E la vicinanza dei dati è un termine che in realtà ho

248
00:12:02,940 --> 00:12:06,870
‫appena inventato, ma ciò che significa è quanto i dati sono realmente

249
00:12:06,870 --> 00:12:10,109
‫correlati e come vogliamo interrogare i dati dal database.

250
00:12:10,109 --> 00:12:11,850
‫E questo avrà più

251
00:12:11,850 --> 00:12:14,180
‫senso quando ne parleremo tra un momento.

252
00:12:14,180 --> 00:12:17,330
‫Ora per prendere effettivamente la decisione; dobbiamo combinare

253
00:12:17,330 --> 00:12:19,350
‫tutti e tre questi

254
00:12:19,350 --> 00:12:21,792
‫criteri e non usarne solo uno isolatamente.

255
00:12:21,792 --> 00:12:25,230
‫Quindi, per esempio; solo perché il criterio numero uno dice

256
00:12:25,230 --> 00:12:28,380
‫di incorporare non significa che non abbiamo bisogno di

257
00:12:28,380 --> 00:12:30,425
‫guardare gli altri due criteri.

258
00:12:30,425 --> 00:12:34,124
‫Va bene e iniziamo con il tipo di relazione.

259
00:12:34,124 --> 00:12:37,968
‫Quindi, di solito, quando abbiamo una relazione da uno a pochi,

260
00:12:37,968 --> 00:12:40,700
‫incorporeremo sempre il set di dati correlato nel

261
00:12:40,700 --> 00:12:43,430
‫set di dati principale proprio come abbiamo

262
00:12:43,430 --> 00:12:45,860
‫appreso nell'ultima diapositiva. Destra.

263
00:12:45,860 --> 00:12:49,110
‫Ora in una relazione uno a molti; le cose

264
00:12:49,110 --> 00:12:52,880
‫sono un po' più confuse, quindi va bene incorporare o fare riferimento.

265
00:12:52,880 --> 00:12:55,140
‫In tal caso dovremo decidere secondo

266
00:12:55,140 --> 00:12:57,304
‫gli altri due criteri.

267
00:12:57,304 --> 00:12:59,825
‫Ora, d'altra parte, su una relazione uno

268
00:12:59,825 --> 00:13:03,894
‫a una tonnellata o molti a molti di solito facciamo sempre

269
00:13:03,894 --> 00:13:06,811
‫riferimento ai dati. Questo perché se lo incorporassimo

270
00:13:06,811 --> 00:13:10,004
‫effettivamente in questo caso potremmo creare rapidamente un documento troppo grande.

271
00:13:10,004 --> 00:13:14,902
‫Anche potenzialmente superando il massimo di 16 megabyte.

272
00:13:14,902 --> 00:13:18,214
‫E quindi la soluzione è ovviamente fare riferimento

273
00:13:18,214 --> 00:13:22,090
‫o normalizzare i dati. E come rapido esempio;

274
00:13:22,090 --> 00:13:24,142
‫diciamo che nel nostro esempio di

275
00:13:24,142 --> 00:13:27,830
‫database di film abbiamo circa 100 immagini associate a ciascun film.

276
00:13:27,830 --> 00:13:30,874
‫Quindi potremmo dire che è una relazione uno a

277
00:13:30,874 --> 00:13:34,230
‫molti, ma incorporeremo il set di dati o dovremmo piuttosto fare

278
00:13:34,230 --> 00:13:37,523
‫riferimento a loro qui. Beh, non lo sappiamo davvero.

279
00:13:37,523 --> 00:13:40,571
‫Quindi diamo un'occhiata agli altri due criteri.

280
00:13:40,571 --> 00:13:44,420
‫Quindi il secondo riguarda i modelli di accesso ai dati in

281
00:13:44,420 --> 00:13:46,290
‫cui è solo una

282
00:13:46,290 --> 00:13:48,242
‫descrizione fantasiosa per valutare se un

283
00:13:48,242 --> 00:13:51,559
‫determinato set di dati viene principalmente scritto o letto principalmente.

284
00:13:51,559 --> 00:13:55,760
‫Quindi, se il set di dati su cui stiamo decidendo è per lo

285
00:13:55,760 --> 00:13:58,179
‫più letto e i dati non

286
00:13:58,179 --> 00:14:01,620
‫vengono aggiornati molto, probabilmente dovremmo incorporare quel set di dati.

287
00:14:01,620 --> 00:14:04,690
‫Quindi un alto rapporto di lettura/scrittura significa semplicemente che

288
00:14:04,690 --> 00:14:07,100
‫c'è molta più lettura che scrittura.

289
00:14:07,100 --> 00:14:11,100
‫E ancora, un set di dati del genere è un buon candidato

290
00:14:11,100 --> 00:14:11,983
‫per l'incorporamento.

291
00:14:12,830 --> 00:14:15,980
‫La ragione di ciò è che incorporando abbiamo solo bisogno

292
00:14:15,980 --> 00:14:18,379
‫di un viaggio nel database per query.

293
00:14:18,379 --> 00:14:22,197
‫Mentre per la referenziazione occorrono due viaggi. Destra.

294
00:14:22,197 --> 00:14:25,660
‫Quindi, se incorporiamo dati che vengono letti molto;

295
00:14:25,660 --> 00:14:28,383
‫in ogni query salviamo un

296
00:14:28,383 --> 00:14:32,147
‫viaggio nel database rendendo l'intero processo molto più performante.

297
00:14:32,147 --> 00:14:35,260
‫Quindi penso che il nostro esempio di immagine del

298
00:14:35,260 --> 00:14:38,320
‫film sarebbe effettivamente un buon candidato per l'incorporamento.

299
00:14:38,320 --> 00:14:41,543
‫Perché una volta che le 100 immagini vengono

300
00:14:41,543 --> 00:14:43,920
‫salvate nel database non vengono più

301
00:14:43,920 --> 00:14:46,930
‫aggiornate realmente perché non c'è davvero nulla da

302
00:14:46,930 --> 00:14:50,057
‫aggiornare su un'immagine. Giusto, quindi si

303
00:14:50,057 --> 00:14:52,563
‫tratta solo di leggere e quindi in

304
00:14:52,563 --> 00:14:55,501
‫base a questo criterio incorporeremmo i documenti immagine.

305
00:14:55,501 --> 00:14:59,092
‫Ora, d'altra parte, se i nostri dati vengono

306
00:14:59,092 --> 00:15:03,118
‫aggiornati molto, dovremmo considerare di fare riferimento o normalizzare i dati.

307
00:15:03,118 --> 00:15:06,700
‫Questo perché è più lavoro per il motore del

308
00:15:06,700 --> 00:15:08,870
‫database aggiornare e incorporare un

309
00:15:08,870 --> 00:15:11,600
‫documento rispetto a un semplice documento autonomo.

310
00:15:11,600 --> 00:15:13,980
‫E poiché il nostro obiettivo principale è la prestazione;

311
00:15:13,980 --> 00:15:15,917
‫normalizziamo semplicemente il set di dati.

312
00:15:15,917 --> 00:15:19,653
‫Nel nostro esempio diciamo che ogni film ha molte recensioni

313
00:15:19,653 --> 00:15:23,284
‫e ogni recensione può essere contrassegnata come utile dall'utente.

314
00:15:23,284 --> 00:15:27,560
‫Quindi ogni volta che qualcuno fa clic su questa recensione è stato utile

315
00:15:27,560 --> 00:15:29,780
‫nella nostra applicazione. Dobbiamo

316
00:15:29,780 --> 00:15:31,740
‫aggiornare il documento corrispondente.

317
00:15:31,740 --> 00:15:35,030
‫E questo significa che i dati possono cambiare continuamente

318
00:15:35,030 --> 00:15:38,520
‫e quindi questo è un ottimo candidato per la normalizzazione.

319
00:15:38,520 --> 00:15:41,420
‫Ancora una volta perché non vogliamo interrogare continuamente

320
00:15:41,420 --> 00:15:45,190
‫i film se tutto ciò che vogliamo davvero aggiornare sono

321
00:15:45,190 --> 00:15:47,230
‫le recensioni contrassegnandole come utili.

322
00:15:47,230 --> 00:15:49,464
‫Ok, ha senso?

323
00:15:49,464 --> 00:15:53,500
‫E infine l'ultimo criterio che chiamo vicinanza dei dati; che è

324
00:15:53,500 --> 00:15:56,320
‫proprio come una misura per quanto i

325
00:15:56,320 --> 00:15:59,469
‫dati sono correlati. Quindi, se i

326
00:15:59,469 --> 00:16:02,890
‫due set di dati appartengono davvero intrinsecamente insieme,

327
00:16:02,890 --> 00:16:05,880
‫allora dovrebbero probabilmente essere incorporati l'uno nell'altro.

328
00:16:05,880 --> 00:16:10,440
‫Nel nostro esempio; tutti gli utenti possono avere molti indirizzi e-mail

329
00:16:10,440 --> 00:16:13,780
‫sul proprio account e poiché sono così intrinsecamente

330
00:16:13,780 --> 00:16:17,190
‫connessi all'utente, non c'è dubbio che le e-mail

331
00:16:17,190 --> 00:16:19,920
‫dovrebbero essere incorporate nel documento.

332
00:16:19,920 --> 00:16:23,830
‫Ora, se abbiamo spesso bisogno di interrogare entrambi i set di dati

333
00:16:23,830 --> 00:16:26,388
‫da soli, questo è un ottimo motivo

334
00:16:26,388 --> 00:16:29,696
‫per normalizzare i dati in due set di dati separati.

335
00:16:29,696 --> 00:16:32,790
‫Anche se sono strettamente imparentati.

336
00:16:32,790 --> 00:16:35,227
‫Quindi immagina che nella nostra app

337
00:16:35,227 --> 00:16:40,227
‫abbiamo un quiz in cui gli utenti devono identificare un film in base alle immagini.

338
00:16:40,440 --> 00:16:43,080
‫Ciò significa che interrogheremo molte immagini

339
00:16:43,080 --> 00:16:44,180
‫da sole.

340
00:16:44,180 --> 00:16:47,756
‫Quindi senza necessariamente chiedere i film stessi.

341
00:16:47,756 --> 00:16:50,640
‫E quindi se applichiamo questo terzo criterio;

342
00:16:50,640 --> 00:16:54,137
‫arriviamo alla conclusione che dovremmo effettivamente normalizzare il set

343
00:16:54,137 --> 00:16:56,759
‫di dati dell'immagine. Va bene.

344
00:16:56,759 --> 00:17:00,770
‫Perché ancora una volta se implementiamo questa funzionalità di quiz;

345
00:17:00,770 --> 00:17:04,057
‫le immagini verranno sempre interrogate da sole.

346
00:17:04,057 --> 00:17:07,422
‫Quindi, tutto ciò mostra che dovremmo davvero guardare tutti

347
00:17:07,422 --> 00:17:09,850
‫e tre i criteri insieme

348
00:17:09,850 --> 00:17:12,700
‫piuttosto che uno solo di essi isolatamente.

349
00:17:12,700 --> 00:17:15,841
‫Perché ciò potrebbe portare a decisioni meno ottimali.

350
00:17:15,841 --> 00:17:18,908
‫E dico meno ottimale invece di sbagliato

351
00:17:18,908 --> 00:17:21,766
‫perché non sono modi completamente giusti

352
00:17:21,766 --> 00:17:25,262
‫o completamente sbagliati di modellare i nostri dati.

353
00:17:25,262 --> 00:17:28,970
‫Non ci sono regole rigide; queste sono proprio delle linee guida che

354
00:17:28,970 --> 00:17:31,380
‫puoi seguire per trovare il modo

355
00:17:31,380 --> 00:17:33,860
‫probabilmente più corretto di strutturare i tuoi dati.

356
00:17:33,860 --> 00:17:37,077
‫Ma ancora una volta, è difficile sbagliarsi davvero.

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

358
00:17:39,740 --> 00:17:43,110
‫Ora, diciamo che abbiamo scelto di normalizzare i nostri

359
00:17:43,110 --> 00:17:44,270
‫set di dati.

360
00:17:44,270 --> 00:17:46,653
‫Quindi, in altre parole, per fare riferimento ai dati.

361
00:17:46,653 --> 00:17:49,380
‫Dopodiché, dobbiamo ancora scegliere

362
00:17:49,380 --> 00:17:52,840
‫tra tre diversi tipi di referenziazione.

363
00:17:52,840 --> 00:17:55,460
‫Referenziazione del bambino, referenziazione del genitore

364
00:17:55,460 --> 00:17:57,540
‫e referenziazione bidirezionale.

365
00:17:57,540 --> 00:18:00,767
‫Quindi il primo tipo è il riferimento ai bambini.

366
00:18:00,767 --> 00:18:04,440
‫Qual è il tipo di riferimento che ti ho mostrato prima.

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

368
00:18:05,470 --> 00:18:07,850
‫E non prendiamo l'esempio di registrazione degli errori che

369
00:18:07,850 --> 00:18:10,128
‫ho menzionato prima. Dove potremmo

370
00:18:10,128 --> 00:18:13,021
‫potenzialmente avere milioni di documenti bloccati.

371
00:18:13,021 --> 00:18:17,300
‫Quindi nel referenziamento dei bambini; fondamentalmente manteniamo i riferimenti ai

372
00:18:17,300 --> 00:18:20,460
‫relativi documenti figlio in un documento padre.

373
00:18:20,460 --> 00:18:22,941
‫E di solito sono memorizzati in un array.

374
00:18:22,941 --> 00:18:25,735
‫Quindi vedi che ogni registro ha un ID

375
00:18:25,735 --> 00:18:29,040
‫e quindi nel documento dell'app c'è quell'array con tutti

376
00:18:29,040 --> 00:18:31,358
‫questi ID. Destra?

377
00:18:31,358 --> 00:18:34,400
‫Tuttavia, il problema qui è che questa

378
00:18:34,400 --> 00:18:39,320
‫serie di ID può diventare molto grande se ci sono molti bambini.

379
00:18:39,320 --> 00:18:42,230
‫E questo è un anti-pattern in MongoDB.

380
00:18:42,230 --> 00:18:45,156
‫Quindi qualcosa che dovremmo evitare a tutti i costi.

381
00:18:45,156 --> 00:18:47,660
‫Inoltre, la referenziazione dei bambini

382
00:18:47,660 --> 00:18:51,410
‫fa sì che genitori e figli siano strettamente legati.

383
00:18:51,410 --> 00:18:54,840
‫Il che non è sempre l'ideale. Ma questo è esattamente il

384
00:18:54,840 --> 00:18:57,020
‫motivo per cui abbiamo le referenze dei genitori.

385
00:18:57,020 --> 00:19:00,300
‫Quindi nella referenziazione dei genitori; in realtà

386
00:19:00,300 --> 00:19:01,870
‫funziona al contrario.

387
00:19:01,870 --> 00:19:05,570
‫Quindi qui in ogni documento figlio manteniamo un

388
00:19:05,570 --> 00:19:07,430
‫riferimento all'elemento genitore.

389
00:19:07,430 --> 00:19:10,267
‫Quindi il nome genitore di riferimento.

390
00:19:10,267 --> 00:19:13,890
‫In questo esempio l'ID app è 23 e quindi in

391
00:19:13,890 --> 00:19:16,640
‫ogni registro c'è il campo app con

392
00:19:16,640 --> 00:19:18,990
‫l'ID 23 al suo interno.

393
00:19:18,990 --> 00:19:21,660
‫In modo che il bambino conosca sempre il suo genitore.

394
00:19:21,660 --> 00:19:24,920
‫E quindi in questo caso il genitore in realtà non sa

395
00:19:24,920 --> 00:19:26,080
‫nulla dei figli.

396
00:19:26,080 --> 00:19:28,768
‫Non chi sono e non quanti sono.

397
00:19:28,768 --> 00:19:32,890
‫Quindi, sono molto più isolati e autonomi.

398
00:19:32,890 --> 00:19:35,326
‫In questo, a volte può essere utile.

399
00:19:35,326 --> 00:19:38,880
‫Quindi quale di questi due tipi è effettivamente migliore per

400
00:19:38,880 --> 00:19:40,527
‫questa relazione di dati.

401
00:19:40,527 --> 00:19:42,820
‫E ricorda come ho detto che potrebbero

402
00:19:42,820 --> 00:19:45,860
‫esserci milioni di registri e quindi supponiamo che ci siano

403
00:19:45,860 --> 00:19:47,652
‫due milioni di documenti registrati.

404
00:19:47,652 --> 00:19:51,340
‫In un caso di riferimento figlio, ciò significherebbe che ci

405
00:19:51,340 --> 00:19:53,209
‫sono due milioni di

406
00:19:53,209 --> 00:19:55,091
‫riferimenti ID nel documento dell'app.

407
00:19:55,091 --> 00:19:58,300
‫Destra? Ora ricorda anche come ho detto

408
00:19:58,300 --> 00:20:00,545
‫che c'è un limite di 16 megabyte sui documenti.

409
00:20:00,545 --> 00:20:04,302
‫Quindi, se continuassimo ad aggiungere e aggiungere questi ID figlio

410
00:20:04,302 --> 00:20:06,716
‫nell'array sul genitore; quindi raggiungeremmo abbastanza

411
00:20:06,716 --> 00:20:09,575
‫rapidamente quel limite di 16 megabyte che

412
00:20:09,575 --> 00:20:11,772
‫ogni documento Bson può contenere.

413
00:20:11,772 --> 00:20:14,702
‫Semplicemente perché quell'array crescerà così tanto.

414
00:20:14,702 --> 00:20:17,210
‫Quindi non funzionerà davvero.

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

416
00:20:18,510 --> 00:20:20,590
‫D'altra parte con il riferimento

417
00:20:20,590 --> 00:20:22,990
‫del genitore che il problema non accadrà.

418
00:20:22,990 --> 00:20:25,570
‫Avremo semplicemente due milioni di documenti

419
00:20:25,570 --> 00:20:30,540
‫bloccati proprio come prima, ma ognuno di essi possiede l'ID del suo genitore.

420
00:20:30,540 --> 00:20:33,098
‫Ma non esiste un array

421
00:20:33,098 --> 00:20:35,740
‫che crescerà indefinitamente e quindi il

422
00:20:35,740 --> 00:20:38,443
‫riferimento genitore sarebbe la soluzione migliore qui.

423
00:20:39,380 --> 00:20:41,901
‫Quindi la conclusione di tutto questo è che in

424
00:20:41,901 --> 00:20:44,385
‫generale il riferimento ai bambini è meglio usato per

425
00:20:44,385 --> 00:20:48,008
‫relazioni da uno a pochi. Dove sappiamo in anticipo che

426
00:20:48,008 --> 00:20:51,118
‫la serie di documenti figlio non crescerà così tanto.

427
00:20:51,118 --> 00:20:54,573
‫D'altra parte, il riferimento dei genitori è meglio utilizzato

428
00:20:54,573 --> 00:20:58,690
‫per relazioni uno a molti e uno a una tonnellata

429
00:20:58,690 --> 00:21:00,927
‫come questa. Va bene?

430
00:21:00,927 --> 00:21:04,610
‫Quindi, ancora una volta, tieni sempre presente che uno

431
00:21:04,610 --> 00:21:07,920
‫dei principi più importanti della modellazione dei

432
00:21:07,920 --> 00:21:11,900
‫dati MongoDB è che l'array non dovrebbe mai crescere indefinitamente.

433
00:21:11,900 --> 00:21:15,420
‫Per non infrangere mai quel limite di 16 megabyte.

434
00:21:15,420 --> 00:21:18,170
‫Inoltre, non vogliamo inviare ai nostri utenti un array

435
00:21:18,170 --> 00:21:20,730
‫con migliaia di ID ogni volta che richiedono

436
00:21:20,730 --> 00:21:24,340
‫un set di dati padre. Va bene?

437
00:21:24,340 --> 00:21:26,900
‫Quindi questa logica aveva senso per te?

438
00:21:26,900 --> 00:21:29,660
‫Quindi passiamo al terzo tipo di referenziazione

439
00:21:29,660 --> 00:21:31,870
‫che è la referenziazione bidirezionale.

440
00:21:31,870 --> 00:21:34,395
‫E questa volta con l'esempio del film e dell'attore

441
00:21:34,395 --> 00:21:36,380
‫che ti ho mostrato quando abbiamo parlato

442
00:21:36,380 --> 00:21:39,364
‫di molte a molte relazioni. Ricordati che?

443
00:21:39,364 --> 00:21:42,229
‫Quindi, di nuovo, ogni film ha molti attori

444
00:21:42,229 --> 00:21:44,880
‫e ogni attore recita in molti film.

445
00:21:44,880 --> 00:21:48,464
‫E quindi questa è una tipica relazione molti a molti.

446
00:21:48,464 --> 00:21:52,100
‫E di solito usiamo questo riferimento bidirezionale per progettare

447
00:21:52,100 --> 00:21:55,346
‫relazioni molti a molti. E funziona così;

448
00:21:55,346 --> 00:21:59,370
‫in ogni film manterremo i riferimenti a tutti gli attori

449
00:21:59,370 --> 00:22:03,980
‫che recitano in quel film. Quindi un po' come nei riferimenti ai bambini.

450
00:22:03,980 --> 00:22:07,000
‫Tuttavia e allo stesso tempo in ogni attore

451
00:22:07,000 --> 00:22:09,570
‫conserviamo anche riferimenti a tutti i film

452
00:22:09,570 --> 00:22:11,660
‫in cui l'attore ha recitato.

453
00:22:11,660 --> 00:22:15,120
‫Quindi film e attori sono collegati in entrambe le direzioni.

454
00:22:15,120 --> 00:22:17,900
‫In quindi il nome bidirezionale di riferimento.

455
00:22:17,900 --> 00:22:19,950
‫E questo rende davvero facile

456
00:22:19,950 --> 00:22:23,290
‫la ricerca di film e attori in modo completamente indipendente.

457
00:22:23,290 --> 00:22:25,910
‫Rendendo anche facile trovare gli attori

458
00:22:25,910 --> 00:22:29,029
‫associati a ciascun film e i film associati

459
00:22:29,029 --> 00:22:30,383
‫a ciascun attore.

460
00:22:31,623 --> 00:22:32,560
‫(respiro profondo)

461
00:22:32,560 --> 00:22:34,747
‫Questa è stata davvero una conferenza piuttosto lunga.

462
00:22:34,747 --> 00:22:38,030
‫Con molti nuovi concetti, principi e

463
00:22:38,030 --> 00:22:40,220
‫linee guida da ricordare.

464
00:22:40,220 --> 00:22:43,460
‫Quindi, per aiutarti in questo; ecco un breve riassunto e

465
00:22:43,460 --> 00:22:46,650
‫alcune linee guida più generali a cui puoi dare

466
00:22:46,650 --> 00:22:48,423
‫un'occhiata quando ne hai bisogno.

467
00:22:49,260 --> 00:22:52,753
‫Quindi il principio più importante è: strutturare i dati in modo

468
00:22:52,753 --> 00:22:56,120
‫che corrispondano ai modi in cui l'applicazione esegue query e

469
00:22:56,120 --> 00:22:57,436
‫aggiorna i dati.

470
00:22:57,436 --> 00:23:01,400
‫O in altre parole: identifica prima le domande che emergono dai casi

471
00:23:01,400 --> 00:23:03,784
‫d'uso della tua applicazione, quindi modella i

472
00:23:03,784 --> 00:23:06,634
‫tuoi dati in modo che le domande possano

473
00:23:06,634 --> 00:23:08,995
‫ottenere risposta nel modo più efficiente.

474
00:23:08,995 --> 00:23:12,610
‫Per esempio; quando ho bisogno di interrogare film e attori

475
00:23:12,610 --> 00:23:16,130
‫sempre insieme o ci sono scenari in cui interrogo solo

476
00:23:16,130 --> 00:23:18,041
‫film o solo attori.

477
00:23:18,041 --> 00:23:20,528
‫Quel tipo di domande è su cosa si

478
00:23:20,528 --> 00:23:22,930
‫baserà il tuo modello di dati.

479
00:23:22,930 --> 00:23:26,730
‫In generale, preferire sempre l'incorporamento, a meno che non vi sia una

480
00:23:26,730 --> 00:23:28,440
‫buona ragione per non farlo.

481
00:23:28,440 --> 00:23:32,513
‫Soprattutto su uno a pochi e uno a molti rapporti.

482
00:23:33,370 --> 00:23:37,713
‫Successivamente, una relazione uno a tonnellata o molti a molti è di

483
00:23:37,713 --> 00:23:41,543
‫solito una buona ragione per fare riferimento invece di incorporare.

484
00:23:41,543 --> 00:23:45,734
‫Inoltre, preferire il riferimento quando i dati vengono aggiornati molto

485
00:23:45,734 --> 00:23:50,717
‫e se è necessario accedere frequentemente a un set di dati da solo.

486
00:23:50,717 --> 00:23:55,340
‫Utilizzare l'incorporamento quando i dati vengono per lo più letti ma aggiornati raramente e

487
00:23:55,340 --> 00:23:58,469
‫quando due set di dati appartengono intrinsecamente insieme.

488
00:23:58,469 --> 00:24:02,840
‫Non consentire agli array di crescere indefinitamente.

489
00:24:02,840 --> 00:24:05,982
‫Pertanto, se vuoi normalizzare; usa il riferimento figlio per

490
00:24:05,982 --> 00:24:09,680
‫le relazioni uno a molti e il riferimento genitore per le

491
00:24:09,680 --> 00:24:11,856
‫relazioni uno a una tonnellata.

492
00:24:11,856 --> 00:24:15,160
‫E infine usa il riferimento bidirezionale per

493
00:24:15,160 --> 00:24:17,520
‫le relazioni molti a molti.

494
00:24:17,520 --> 00:24:18,720
‫Va bene?

495
00:24:18,720 --> 00:24:21,202
‫E questo praticamente riassume.

496
00:24:21,202 --> 00:24:23,970
‫In realtà ti consiglierei di guardare questo

497
00:24:23,970 --> 00:24:27,144
‫video due volte, se puoi, proprio per l'importanza

498
00:24:27,144 --> 00:24:30,091
‫di questo materiale. Va bene?

499
00:24:30,091 --> 00:24:33,363
‫Comunque, ci vediamo al prossimo video.