1
00:00:01,090 --> 00:00:03,210
‫Istruttore: Proprio come nelle

2
00:00:03,210 --> 00:00:05,810
‫sezioni precedenti, prima di immergerci in una

3
00:00:05,810 --> 00:00:08,590
‫nuova tecnologia, impariamo effettivamente di cosa si tratta.

4
00:00:08,590 --> 00:00:12,180
‫Quindi, in questo caso, impariamo cos'è effettivamente MongoDB, come

5
00:00:12,180 --> 00:00:14,750
‫funziona e una rapida panoramica

6
00:00:14,750 --> 00:00:18,600
‫di come si confronta con i database più tradizionali.

7
00:00:18,600 --> 00:00:21,340
‫E cominciamo con una semplice panoramica.

8
00:00:21,340 --> 00:00:24,830
‫Quindi MongoDB è ovviamente un database, ed

9
00:00:24,830 --> 00:00:27,870
‫è un cosiddetto database NoSQL.

10
00:00:27,870 --> 00:00:30,930
‫Ora alcune persone dicono anche No S Q

11
00:00:30,930 --> 00:00:34,240
‫L, ma io continuerò a dire "nessun seguito", va bene?

12
00:00:34,240 --> 00:00:37,010
‫Ora, l'altro tipo di database, che

13
00:00:37,010 --> 00:00:40,620
‫è un po' più tradizionale, è il database

14
00:00:40,620 --> 00:00:43,760
‫relazionale, a cui viene spesso confrontato NoSQL.

15
00:00:43,760 --> 00:00:48,330
‫Ad ogni modo, in Mongo, che possiamo anche dire al posto

16
00:00:48,330 --> 00:00:52,570
‫di MongoDB, ogni database può contenere una o più raccolte.

17
00:00:52,570 --> 00:00:55,100
‫Quindi, se in realtà provieni da

18
00:00:55,100 --> 00:00:58,530
‫uno di questi sistemi di database relazionali più tradizionali,

19
00:00:58,530 --> 00:01:02,760
‫puoi pensare a una raccolta come a una tabella di dati.

20
00:01:02,760 --> 00:01:05,520
‫Quindi, ogni raccolta può contenere una

21
00:01:05,520 --> 00:01:09,130
‫o più strutture di dati chiamate documenti e,

22
00:01:09,130 --> 00:01:11,870
‫ancora, in un database relazionale,

23
00:01:11,870 --> 00:01:15,380
‫un documento sarebbe una riga in una tabella.

24
00:01:15,380 --> 00:01:17,770
‫Quindi ogni documento contiene i dati

25
00:01:17,770 --> 00:01:20,600
‫su una singola entità, ad esempio, un

26
00:01:20,600 --> 00:01:24,870
‫post sul blog o un utente o una recensione, o

27
00:01:24,870 --> 00:01:26,780
‫qualsiasi altra cosa.

28
00:01:26,780 --> 00:01:29,030
‫Hai capito il punto, vero?

29
00:01:29,030 --> 00:01:32,270
‫Ora la raccolta è come la struttura padre

30
00:01:32,270 --> 00:01:34,730
‫che contiene tutte queste entità.

31
00:01:34,730 --> 00:01:38,120
‫Ad esempio, una raccolta di blog per tutti i

32
00:01:38,120 --> 00:01:41,730
‫post, una raccolta di utenti o una raccolta di recensioni.

33
00:01:41,730 --> 00:01:44,060
‫E puoi anche vedere qui che il

34
00:01:44,060 --> 00:01:47,740
‫documento ha un formato dati che assomiglia molto a JSON, il

35
00:01:47,740 --> 00:01:49,810
‫che renderà il nostro lavoro

36
00:01:49,810 --> 00:01:52,520
‫molto più semplice quando inizieremo a gestire questi documenti.

37
00:01:52,520 --> 00:01:55,180
‫E ovviamente ne parleremo molto in seguito,

38
00:01:55,180 --> 00:01:58,543
‫ma per ora impariamo a conoscere le caratteristiche principali di Mongo.

39
00:01:59,460 --> 00:02:02,260
‫Quindi, secondo il sito Web di MongoDB,

40
00:02:02,260 --> 00:02:05,990
‫MongoDB è un database di documenti con la scalabilità

41
00:02:05,990 --> 00:02:08,330
‫e la flessibilità che desideri

42
00:02:08,330 --> 00:02:12,200
‫e con le query e l'indicizzazione di cui hai bisogno.

43
00:02:12,200 --> 00:02:14,710
‫Ora, sembra un po' esagerato, quindi

44
00:02:14,710 --> 00:02:17,503
‫proviamo a capire cosa significa in realtà.

45
00:02:18,490 --> 00:02:23,250
‫Quindi, come abbiamo visto prima, MongoDB è un database basato su documenti, quindi

46
00:02:23,250 --> 00:02:25,750
‫memorizza i dati in documenti che

47
00:02:25,750 --> 00:02:29,660
‫sono strutture dati accoppiate a valori di campo come JSON.

48
00:02:29,660 --> 00:02:33,020
‫Quindi, di nuovo, memorizza i dati in questi documenti

49
00:02:33,020 --> 00:02:34,840
‫anziché nelle righe in

50
00:02:34,840 --> 00:02:37,530
‫una tabella come nei database relazionali tradizionali.

51
00:02:37,530 --> 00:02:39,930
‫Si tratta quindi di un database

52
00:02:39,930 --> 00:02:42,190
‫NoSQL e non relazionale.

53
00:02:42,190 --> 00:02:45,690
‫Inoltre, MongoDB ha una scalabilità integrata, che semplifica la

54
00:02:45,690 --> 00:02:48,360
‫distribuzione dei dati su più macchine

55
00:02:48,360 --> 00:02:50,920
‫man mano che le tue app

56
00:02:50,920 --> 00:02:52,620
‫ottengono sempre più

57
00:02:52,620 --> 00:02:56,090
‫utenti e iniziano a generare una tonnellata di dati.

58
00:02:56,090 --> 00:02:59,710
‫Quindi, qualunque cosa tu faccia, MongoDB ti renderà

59
00:02:59,710 --> 00:03:01,110
‫molto facile crescere.

60
00:03:01,110 --> 00:03:04,010
‫Successivamente, un'altra grande caratteristica di MongoDB è

61
00:03:04,010 --> 00:03:06,360
‫la sua grande flessibilità.

62
00:03:06,360 --> 00:03:10,210
‫Quindi non è necessario definire uno schema di dati del documento prima

63
00:03:10,210 --> 00:03:12,210
‫di riempirlo con i dati, il

64
00:03:12,210 --> 00:03:15,460
‫che significa che ogni documento può avere un numero e

65
00:03:15,460 --> 00:03:17,160
‫un tipo di campi diversi.

66
00:03:17,160 --> 00:03:20,120
‫E possiamo anche cambiare questi campi in ogni momento.

67
00:03:20,120 --> 00:03:22,130
‫E tutto questo è davvero

68
00:03:22,130 --> 00:03:24,460
‫in linea con alcune situazioni aziendali del mondo

69
00:03:24,460 --> 00:03:26,690
‫reale, e quindi può diventare piuttosto utile.

70
00:03:26,690 --> 00:03:31,550
‫MongoDB è anche un sistema di database molto performante.

71
00:03:31,550 --> 00:03:34,680
‫Grazie a funzionalità come i modelli di dati

72
00:03:34,680 --> 00:03:37,645
‫incorporati, l'indicizzazione, lo sharding, i documenti flessibili

73
00:03:37,645 --> 00:03:41,290
‫di cui abbiamo già parlato, la duplicazione nativa e

74
00:03:41,290 --> 00:03:43,010
‫molto altro ancora.

75
00:03:43,010 --> 00:03:45,850
‫E non è necessario che tu sappia tutto

76
00:03:45,850 --> 00:03:50,320
‫questo, ovviamente, ma è sicuramente bello sapere che MongoDB è altamente performante

77
00:03:50,320 --> 00:03:52,100
‫se ne abbiamo bisogno.

78
00:03:52,100 --> 00:03:55,270
‫Infine, volevo solo aggiungere che MongoDB

79
00:03:55,270 --> 00:03:57,710
‫è un database gratuito

80
00:03:57,710 --> 00:04:01,350
‫e open source, pubblicato con licenza SSPL.

81
00:04:01,350 --> 00:04:04,700
‫Quindi, in sintesi, possiamo dire che MongoDB è

82
00:04:04,700 --> 00:04:06,770
‫un ottimo sistema di

83
00:04:06,770 --> 00:04:09,600
‫database per costruire molti tipi di applicazioni

84
00:04:09,600 --> 00:04:11,900
‫web moderne, scalabili e flessibili.

85
00:04:11,900 --> 00:04:15,450
‫E infatti, Mongo è probabilmente il database più utilizzato

86
00:04:15,450 --> 00:04:18,250
‫senza JS, quindi è perfetto per noi

87
00:04:18,250 --> 00:04:20,690
‫da utilizzare in questo corso.

88
00:04:20,690 --> 00:04:22,970
‫Ok, ora parliamo un po'

89
00:04:22,970 --> 00:04:25,910
‫più a fondo di questi documenti e, tornando

90
00:04:25,910 --> 00:04:28,540
‫all'esempio dei post del nostro blog dall'inizio,

91
00:04:28,540 --> 00:04:31,330
‫questa potrebbe essere una rappresentazione molto semplice

92
00:04:31,330 --> 00:04:34,140
‫di un documento di un singolo post, giusto?

93
00:04:34,140 --> 00:04:36,720
‫E ora, solo per fare un confronto,

94
00:04:36,720 --> 00:04:38,930
‫ecco come potrebbero apparire esattamente gli

95
00:04:38,930 --> 00:04:42,250
‫stessi dati come una riga in un database relazionale come

96
00:04:42,250 --> 00:04:45,580
‫MySQL, o anche in un foglio di calcolo Excel, se

97
00:04:45,580 --> 00:04:47,640
‫sei più abituato a questo.

98
00:04:47,640 --> 00:04:49,730
‫Quindi, come ho detto un

99
00:04:49,730 --> 00:04:53,190
‫po' prima, MongoDB utilizza un formato dati simile a

100
00:04:53,190 --> 00:04:56,070
‫JSON per l'archiviazione dei dati chiamato BSON.

101
00:04:56,070 --> 00:04:58,970
‫Sembra sostanzialmente uguale a JSON, ma è

102
00:04:58,970 --> 00:05:01,650
‫digitato, il che significa che

103
00:05:01,650 --> 00:05:05,450
‫tutti i valori avranno un tipo di dati come

104
00:05:05,450 --> 00:05:09,050
‫stringa, booleano, data e insegnante, doppio oggetto o altro.

105
00:05:09,050 --> 00:05:11,890
‫Impareremo tutto su questo più avanti in pratica.

106
00:05:11,890 --> 00:05:15,030
‫Quindi ciò significa che tutti i documenti

107
00:05:15,030 --> 00:05:16,700
‫MongoDB verranno effettivamente

108
00:05:16,700 --> 00:05:20,220
‫digitati, che è diverso da JSON, va bene?

109
00:05:20,220 --> 00:05:23,830
‫Ora, proprio come JSON, anche questi documenti BSON avranno

110
00:05:23,830 --> 00:05:26,570
‫campi e i dati vengono archiviati

111
00:05:26,570 --> 00:05:28,270
‫in coppie chiave-valore.

112
00:05:28,270 --> 00:05:30,840
‫D'altra parte, in un database

113
00:05:30,840 --> 00:05:33,730
‫relazionale, ogni campo è chiamato colonna.

114
00:05:33,730 --> 00:05:35,400
‫Quindi anche qui puoi

115
00:05:35,400 --> 00:05:38,920
‫vedere come questi database organizzano i dati in strutture di

116
00:05:38,920 --> 00:05:42,590
‫tabelle mentre i nostri dati JSON sono molto più flessibili.

117
00:05:42,590 --> 00:05:44,300
‫Prendiamo ad esempio il

118
00:05:44,300 --> 00:05:46,170
‫campo tag, dove in realtà

119
00:05:46,170 --> 00:05:50,470
‫abbiamo un array, quindi abbiamo fondamentalmente più valori per un campo, giusto?

120
00:05:50,470 --> 00:05:54,140
‫Quindi MongoDB, spazio e DV in questo caso.

121
00:05:54,140 --> 00:05:57,040
‫Ma nei database relazionali, ciò non è realmente consentito.

122
00:05:57,040 --> 00:06:00,020
‫Non possiamo avere più valori in un

123
00:06:00,020 --> 00:06:03,100
‫campo, quindi dovremmo effettivamente trovare soluzioni alternative per

124
00:06:03,100 --> 00:06:05,150
‫questo che potrebbero comportare

125
00:06:05,150 --> 00:06:07,550
‫più lavoro e più complicazioni complessive.

126
00:06:07,550 --> 00:06:10,540
‫Ora un'altra caratteristica estremamente importante in MongoDB è

127
00:06:10,540 --> 00:06:13,040
‫il concetto di documenti incorporati, che

128
00:06:13,040 --> 00:06:16,120
‫è, ancora una volta, qualcosa che non è

129
00:06:16,120 --> 00:06:18,290
‫presente nei database relazionali.

130
00:06:18,290 --> 00:06:19,970
‫Quindi, nel nostro campo

131
00:06:19,970 --> 00:06:23,050
‫dei commenti qui, abbiamo un array che contiene tre oggetti.

132
00:06:23,050 --> 00:06:24,500
‫Uno per ogni

133
00:06:24,500 --> 00:06:26,280
‫documento e ognuno di essi

134
00:06:26,280 --> 00:06:28,700
‫potrebbe effettivamente essere il proprio documento, giusto?

135
00:06:28,700 --> 00:06:31,360
‫Quindi immagina di avere una raccolta di

136
00:06:31,360 --> 00:06:34,550
‫commenti che conteneva una serie di documenti di commento.

137
00:06:34,550 --> 00:06:37,670
‫Ognuno di loro potrebbe effettivamente apparire esattamente così,

138
00:06:37,670 --> 00:06:40,600
‫quindi con un autore e con il

139
00:06:40,600 --> 00:06:42,200
‫testo del commento,

140
00:06:42,200 --> 00:06:45,850
‫ma invece di farlo, includiamo questi commenti direttamente nel documento

141
00:06:45,850 --> 00:06:49,610
‫del post del blog, quindi in altre parole, incorporiamo i

142
00:06:49,610 --> 00:06:52,270
‫documenti dei commenti direttamente nel documento postale.

143
00:06:52,270 --> 00:06:55,410
‫Quindi questo processo di incorporamento, o

144
00:06:55,410 --> 00:06:59,070
‫denormalizzazione come possiamo anche chiamarlo, consiste fondamentalmente nell'includere,

145
00:06:59,070 --> 00:07:01,930
‫quindi, nell'incorporare alcuni dati correlati in

146
00:07:01,930 --> 00:07:04,040
‫un unico documento.

147
00:07:04,040 --> 00:07:07,540
‫In questo esempio, i commenti sono correlati al post

148
00:07:07,540 --> 00:07:10,880
‫e quindi sono inclusi nello stesso documento.

149
00:07:10,880 --> 00:07:13,380
‫E questo rende un database più performante in

150
00:07:13,380 --> 00:07:15,760
‫alcune situazioni perché in questo modo può essere

151
00:07:15,760 --> 00:07:17,340
‫più facile leggere tutti

152
00:07:17,340 --> 00:07:20,150
‫i dati di cui abbiamo bisogno tutti in una volta.

153
00:07:20,150 --> 00:07:23,270
‫E questo è qualcosa di cui parleremo molto quando impareremo

154
00:07:23,270 --> 00:07:25,320
‫a modellare i dati, ma

155
00:07:25,320 --> 00:07:28,720
‫per ora spero che questo abbia ancora senso per te.

156
00:07:28,720 --> 00:07:31,850
‫Ora, l'opposto dell'incorporamento o della denormalizzazione, è la

157
00:07:31,850 --> 00:07:35,520
‫normalizzazione, ed è così che i dati vengono sempre modellati

158
00:07:35,520 --> 00:07:37,200
‫nei database relazionali.

159
00:07:37,200 --> 00:07:40,430
‫Quindi, in tal caso, non è possibile incorporare dati

160
00:07:40,430 --> 00:07:42,070
‫e quindi la soluzione

161
00:07:42,070 --> 00:07:44,480
‫è creare una tabella completamente nuova

162
00:07:44,480 --> 00:07:47,320
‫per i commenti e quindi unire le tabelle

163
00:07:47,320 --> 00:07:50,250
‫facendo riferimento al campo ID della tabella dei commenti.

164
00:07:50,250 --> 00:07:52,590
‫Ora non useremo database relazionali in questo

165
00:07:52,590 --> 00:07:55,460
‫corso, ma credo che sia comunque importante conoscere

166
00:07:55,460 --> 00:07:57,510
‫le differenze se vuoi

167
00:07:57,510 --> 00:07:59,630
‫diventare un buon sviluppatore di back-end.

168
00:07:59,630 --> 00:08:01,940
‫Ad ogni modo, e ora solo

169
00:08:01,940 --> 00:08:04,810
‫per finire, altre due cose sui documenti BSON.

170
00:08:04,810 --> 00:08:07,510
‫Innanzitutto, la dimensione massima per ogni

171
00:08:07,510 --> 00:08:12,120
‫documento è attualmente di 16 MB, ma potrebbe aumentare in futuro.

172
00:08:12,120 --> 00:08:16,180
‫E in secondo luogo, ogni documento contiene un ID univoco,

173
00:08:16,180 --> 00:08:19,900
‫che funge da chiave primaria di quel documento.

174
00:08:19,900 --> 00:08:23,780
‫Viene generato automaticamente con il tipo di dati ID oggetto

175
00:08:23,780 --> 00:08:26,000
‫ogni volta che c'è un

176
00:08:26,000 --> 00:08:28,605
‫nuovo documento, quindi non dobbiamo preoccuparcene.

177
00:08:28,605 --> 00:08:32,240
‫Va bene, e questa dovrebbe essere una panoramica abbastanza breve

178
00:08:32,240 --> 00:08:33,610
‫per iniziare e

179
00:08:33,610 --> 00:08:37,210
‫per utilizzare effettivamente MongoDB dalla prossima lezione in poi.

180
00:08:37,210 --> 00:08:38,873
‫Quindi, andiamo avanti ora.