﻿1
00:00:01,090 --> 00:00:03,210
‫Instructeur : Tout comme dans

2
00:00:03,210 --> 00:00:05,810
‫les sections précédentes, avant de plonger dans une

3
00:00:05,810 --> 00:00:08,590
‫nouvelle technologie, apprenons en fait de quoi il s'agit.

4
00:00:08,590 --> 00:00:12,180
‫Donc, dans ce cas, apprenons ce qu'est réellement MongoDB, comment

5
00:00:12,180 --> 00:00:14,750
‫il fonctionne et un aperçu rapide de

6
00:00:14,750 --> 00:00:18,600
‫la façon dont il se compare aux bases de données plus traditionnelles.

7
00:00:18,600 --> 00:00:21,340
‫Et commençons par un simple aperçu.

8
00:00:21,340 --> 00:00:24,830
‫Donc, MongoDB est évidemment une base de données, et

9
00:00:24,830 --> 00:00:27,870
‫c'est une base de données dite NoSQL.

10
00:00:27,870 --> 00:00:30,930
‫Maintenant, certaines personnes disent aussi Non S Q L,

11
00:00:30,930 --> 00:00:34,240
‫mais je vais continuer à dire "pas de suite", d'accord ?

12
00:00:34,240 --> 00:00:37,010
‫Maintenant, l'autre type de base de

13
00:00:37,010 --> 00:00:40,620
‫données, un peu plus traditionnel, est la base de

14
00:00:40,620 --> 00:00:43,760
‫données relationnelle, à laquelle NoSQL est souvent comparé.

15
00:00:43,760 --> 00:00:48,330
‫Quoi qu'il en soit, dans Mongo, ce qu'on peut dire aussi à la place

16
00:00:48,330 --> 00:00:52,570
‫de MongoDB, chaque base de données peut contenir une ou plusieurs collections.

17
00:00:52,570 --> 00:00:55,100
‫Donc, si vous venez de l'un

18
00:00:55,100 --> 00:00:58,530
‫de ces systèmes de bases de données relationnelles plus

19
00:00:58,530 --> 00:01:02,760
‫traditionnels, vous pouvez considérer une collection comme une table de données.

20
00:01:02,760 --> 00:01:05,520
‫Ensuite, chaque collection peut contenir une ou

21
00:01:05,520 --> 00:01:09,130
‫plusieurs structures de données appelées documents, et encore une

22
00:01:09,130 --> 00:01:11,870
‫fois, dans une base de données

23
00:01:11,870 --> 00:01:15,380
‫relationnelle, un document serait une ligne dans une table.

24
00:01:15,380 --> 00:01:17,770
‫Ainsi, chaque document contient les données

25
00:01:17,770 --> 00:01:20,600
‫sur une seule entité, par exemple, un article

26
00:01:20,600 --> 00:01:24,870
‫de blog ou un utilisateur ou une critique, ou quoi que

27
00:01:24,870 --> 00:01:26,780
‫ce soit d'autre, vraiment.

28
00:01:26,780 --> 00:01:29,030
‫Vous comprenez le problème, n'est-ce pas?

29
00:01:29,030 --> 00:01:32,270
‫Maintenant, la collection est comme la structure parente

30
00:01:32,270 --> 00:01:34,730
‫qui contient toutes ces entités.

31
00:01:34,730 --> 00:01:38,120
‫Par exemple, une collection de blogs pour tous

32
00:01:38,120 --> 00:01:41,730
‫les articles, une collection d'utilisateurs ou une collection d'avis.

33
00:01:41,730 --> 00:01:44,060
‫Et vous pouvez également voir ici que

34
00:01:44,060 --> 00:01:47,740
‫le document a un format de données qui ressemble beaucoup à

35
00:01:47,740 --> 00:01:49,810
‫JSON, ce qui facilitera grandement

36
00:01:49,810 --> 00:01:52,520
‫notre travail lorsque nous commencerons à traiter ces documents.

37
00:01:52,520 --> 00:01:55,180
‫Et bien sûr, nous en parlerons beaucoup

38
00:01:55,180 --> 00:01:58,543
‫plus tard, mais pour l'instant, découvrons les principales fonctionnalités de Mongo.

39
00:01:59,460 --> 00:02:02,260
‫Ainsi, selon le site Web de MongoDB,

40
00:02:02,260 --> 00:02:05,990
‫MongoDB est une base de données de documents avec l'évolutivité

41
00:02:05,990 --> 00:02:08,330
‫et la flexibilité que vous

42
00:02:08,330 --> 00:02:12,200
‫souhaitez, ainsi que les requêtes et l'indexation dont vous avez besoin.

43
00:02:12,200 --> 00:02:14,710
‫Maintenant, cela semble un peu exagéré, alors

44
00:02:14,710 --> 00:02:17,503
‫essayons de comprendre ce que cela signifie réellement.

45
00:02:18,490 --> 00:02:23,250
‫Ainsi, comme nous l'avons vu précédemment, MongoDB est une base de données basée sur des documents,

46
00:02:23,250 --> 00:02:25,750
‫elle stocke donc les données dans des documents

47
00:02:25,750 --> 00:02:29,660
‫qui sont des structures de données appariées à valeur de champ comme JSON.

48
00:02:29,660 --> 00:02:33,020
‫Encore une fois, il stocke des données dans ces documents au

49
00:02:33,020 --> 00:02:34,840
‫lieu de lignes dans une

50
00:02:34,840 --> 00:02:37,530
‫table comme dans les bases de données relationnelles traditionnelles.

51
00:02:37,530 --> 00:02:39,930
‫Il s'agit donc d'une base de

52
00:02:39,930 --> 00:02:42,190
‫données NoSQL et non relationnelle.

53
00:02:42,190 --> 00:02:45,690
‫De plus, MongoDB a une évolutivité intégrée, ce qui facilite

54
00:02:45,690 --> 00:02:48,360
‫la distribution des données sur plusieurs machines

55
00:02:48,360 --> 00:02:50,920
‫à mesure que vos applications attirent de

56
00:02:50,920 --> 00:02:52,620
‫plus en plus

57
00:02:52,620 --> 00:02:56,090
‫d'utilisateurs et commencent à générer une tonne de données.

58
00:02:56,090 --> 00:02:59,710
‫Ainsi, quoi que vous fassiez, MongoDB vous facilitera

59
00:02:59,710 --> 00:03:01,110
‫grandement la croissance.

60
00:03:01,110 --> 00:03:04,010
‫Ensuite, une autre grande caractéristique de MongoDB

61
00:03:04,010 --> 00:03:06,360
‫est sa grande flexibilité.

62
00:03:06,360 --> 00:03:10,210
‫Il n'est donc pas nécessaire de définir un schéma de données de document

63
00:03:10,210 --> 00:03:12,210
‫avant de le remplir de données,

64
00:03:12,210 --> 00:03:15,460
‫ce qui signifie que chaque document peut avoir un nombre et

65
00:03:15,460 --> 00:03:17,160
‫un type de champs différents.

66
00:03:17,160 --> 00:03:20,120
‫Et nous pouvons également modifier ces champs tout le temps.

67
00:03:20,120 --> 00:03:22,130
‫Et tout cela correspond vraiment

68
00:03:22,130 --> 00:03:24,460
‫à certaines situations commerciales du monde réel

69
00:03:24,460 --> 00:03:26,690
‫et peut donc devenir très utile.

70
00:03:26,690 --> 00:03:31,550
‫MongoDB est également un système de base de données très performant.

71
00:03:31,550 --> 00:03:34,680
‫Grâce à des fonctionnalités telles que les modèles

72
00:03:34,680 --> 00:03:37,645
‫de données intégrés, l'indexation, le sharding, les

73
00:03:37,645 --> 00:03:41,290
‫documents flexibles dont nous avons déjà parlé, la duplication native

74
00:03:41,290 --> 00:03:43,010
‫et bien plus encore.

75
00:03:43,010 --> 00:03:45,850
‫Et vous n'avez pas besoin de tout savoir, bien

76
00:03:45,850 --> 00:03:50,320
‫sûr, mais il est bien sûr agréable de savoir que MongoDB est très performant

77
00:03:50,320 --> 00:03:52,100
‫si nous en avons besoin.

78
00:03:52,100 --> 00:03:55,270
‫Enfin, je voulais juste ajouter que MongoDB

79
00:03:55,270 --> 00:03:57,710
‫est une base de données

80
00:03:57,710 --> 00:04:01,350
‫gratuite et open source, publiée sous licence SSPL.

81
00:04:01,350 --> 00:04:04,700
‫Donc, en résumé, nous pouvons dire que MongoDB est

82
00:04:04,700 --> 00:04:06,770
‫un excellent système de

83
00:04:06,770 --> 00:04:09,600
‫base de données pour créer de nombreux types

84
00:04:09,600 --> 00:04:11,900
‫d'applications Web modernes, évolutives et flexibles.

85
00:04:11,900 --> 00:04:15,450
‫Et en fait, Mongo est probablement la base de données la plus

86
00:04:15,450 --> 00:04:18,250
‫utilisée sans JS, et c'est donc une solution idéale

87
00:04:18,250 --> 00:04:20,690
‫pour nous à utiliser dans ce cours.

88
00:04:20,690 --> 00:04:22,970
‫Bon, maintenant parlons un peu

89
00:04:22,970 --> 00:04:25,910
‫plus de ces documents, et en revenant à

90
00:04:25,910 --> 00:04:28,540
‫notre exemple d'articles de blog depuis le

91
00:04:28,540 --> 00:04:31,330
‫début, cela pourrait être une représentation très

92
00:04:31,330 --> 00:04:34,140
‫simple d'un seul document d'article, n'est-ce pas ?

93
00:04:34,140 --> 00:04:36,720
‫Et maintenant, juste à titre de comparaison, voici

94
00:04:36,720 --> 00:04:38,930
‫à quoi pourraient ressembler ces mêmes données

95
00:04:38,930 --> 00:04:42,250
‫sous forme de ligne dans une base de données relationnelle

96
00:04:42,250 --> 00:04:45,580
‫comme MySQL, ou même dans une feuille de calcul Excel, si

97
00:04:45,580 --> 00:04:47,640
‫vous y êtes plus habitué.

98
00:04:47,640 --> 00:04:49,730
‫Ainsi, comme je l'ai mentionné

99
00:04:49,730 --> 00:04:53,190
‫un peu plus tôt, MongoDB utilise un format de données similaire

100
00:04:53,190 --> 00:04:56,070
‫à JSON pour le stockage de données appelé BSON.

101
00:04:56,070 --> 00:04:58,970
‫Il ressemble fondamentalement à JSON, mais il

102
00:04:58,970 --> 00:05:01,650
‫est typé, ce qui signifie que

103
00:05:01,650 --> 00:05:05,450
‫toutes les valeurs auront un type de données tel que

104
00:05:05,450 --> 00:05:09,050
‫chaîne, booléen, date et enseignant, objet double ou plus.

105
00:05:09,050 --> 00:05:11,890
‫Nous apprendrons tout cela plus tard dans la pratique.

106
00:05:11,890 --> 00:05:15,030
‫Cela signifie donc que tous les documents

107
00:05:15,030 --> 00:05:16,700
‫MongoDB seront effectivement

108
00:05:16,700 --> 00:05:20,220
‫tapés, ce qui est différent de JSON, d'accord ?

109
00:05:20,220 --> 00:05:23,830
‫Maintenant, tout comme JSON, ces documents BSON auront également

110
00:05:23,830 --> 00:05:26,570
‫des champs et les données sont stockées

111
00:05:26,570 --> 00:05:28,270
‫dans des paires clé-valeur.

112
00:05:28,270 --> 00:05:30,840
‫Par contre, dans une base de

113
00:05:30,840 --> 00:05:33,730
‫données relationnelle, chaque champ est appelé une colonne.

114
00:05:33,730 --> 00:05:35,400
‫Ici encore, vous pouvez

115
00:05:35,400 --> 00:05:38,920
‫voir comment ces bases de données organisent les données dans des

116
00:05:38,920 --> 00:05:42,590
‫structures de table tandis que nos données JSON sont beaucoup plus flexibles.

117
00:05:42,590 --> 00:05:44,300
‫Prenons par exemple le champ

118
00:05:44,300 --> 00:05:46,170
‫de balises, où nous avons en

119
00:05:46,170 --> 00:05:50,470
‫fait un tableau, nous avons donc essentiellement plusieurs valeurs pour un champ, n'est-ce pas ?

120
00:05:50,470 --> 00:05:54,140
‫Donc MongoDB, space et DV dans ce cas.

121
00:05:54,140 --> 00:05:57,040
‫Mais dans les bases de données relationnelles, ce n'est pas vraiment autorisé.

122
00:05:57,040 --> 00:06:00,020
‫Nous ne pouvons pas avoir plusieurs valeurs dans un même

123
00:06:00,020 --> 00:06:03,100
‫champ, et nous devrons donc trouver des solutions de contournement pour

124
00:06:03,100 --> 00:06:05,150
‫cela, ce qui pourrait alors impliquer

125
00:06:05,150 --> 00:06:07,550
‫plus de travail et plus de complications globales.

126
00:06:07,550 --> 00:06:10,540
‫Maintenant, une autre caractéristique extrêmement importante de MongoDB est

127
00:06:10,540 --> 00:06:13,040
‫le concept de documents intégrés, qui est,

128
00:06:13,040 --> 00:06:16,120
‫encore une fois, quelque chose qui n'est pas présent

129
00:06:16,120 --> 00:06:18,290
‫dans les bases de données relationnelles.

130
00:06:18,290 --> 00:06:19,970
‫Donc, dans notre champ de

131
00:06:19,970 --> 00:06:23,050
‫commentaires ici, nous avons un tableau qui contient trois objets.

132
00:06:23,050 --> 00:06:24,500
‫Un pour chaque document,

133
00:06:24,500 --> 00:06:26,280
‫et chacun d'eux pourrait en

134
00:06:26,280 --> 00:06:28,700
‫fait être son propre document, n'est-ce pas ?

135
00:06:28,700 --> 00:06:31,360
‫Imaginez donc que nous ayons une collection

136
00:06:31,360 --> 00:06:34,550
‫de commentaires contenant un tas de documents de commentaires.

137
00:06:34,550 --> 00:06:37,670
‫Chacun d'eux pourrait en fait ressembler exactement à ceci, donc

138
00:06:37,670 --> 00:06:40,600
‫avec un auteur et avec le texte du commentaire,

139
00:06:40,600 --> 00:06:42,200
‫mais au lieu de

140
00:06:42,200 --> 00:06:45,850
‫le faire, nous incluons ces commentaires directement dans le document du

141
00:06:45,850 --> 00:06:49,610
‫billet de blog, donc en d'autres termes, nous intégrons les documents de

142
00:06:49,610 --> 00:06:52,270
‫commentaire directement dans le poster le document.

143
00:06:52,270 --> 00:06:55,410
‫Ainsi, ce processus d'intégration, ou de dénormalisation,

144
00:06:55,410 --> 00:06:59,070
‫comme nous pouvons également l'appeler, consiste essentiellement à inclure,

145
00:06:59,070 --> 00:07:01,930
‫donc, à intégrer certaines données connexes

146
00:07:01,930 --> 00:07:04,040
‫dans un seul document.

147
00:07:04,040 --> 00:07:07,540
‫Dans cet exemple, les commentaires sont liés à la publication

148
00:07:07,540 --> 00:07:10,880
‫et sont donc inclus dans le même document.

149
00:07:10,880 --> 00:07:13,380
‫Et cela rend une base de données plus performante

150
00:07:13,380 --> 00:07:15,760
‫dans certaines situations, car de cette façon, il

151
00:07:15,760 --> 00:07:17,340
‫peut être plus facile de

152
00:07:17,340 --> 00:07:20,150
‫lire toutes les données dont nous avons besoin en même temps.

153
00:07:20,150 --> 00:07:23,270
‫Et c'est quelque chose dont nous allons beaucoup parler lors de

154
00:07:23,270 --> 00:07:25,320
‫l'apprentissage de la modélisation des données,

155
00:07:25,320 --> 00:07:28,720
‫mais pour l'instant, j'espère que cela a toujours du sens pour vous.

156
00:07:28,720 --> 00:07:31,850
‫Maintenant, le contraire de l'intégration ou de la dénormalisation, c'est

157
00:07:31,850 --> 00:07:35,520
‫la normalisation, et c'est ainsi que les données sont toujours modélisées dans

158
00:07:35,520 --> 00:07:37,200
‫les bases de données relationnelles.

159
00:07:37,200 --> 00:07:40,430
‫Donc, dans ce cas, il n'est pas possible d'incorporer des données,

160
00:07:40,430 --> 00:07:42,070
‫et la solution est

161
00:07:42,070 --> 00:07:44,480
‫donc de créer une toute nouvelle table pour

162
00:07:44,480 --> 00:07:47,320
‫les commentaires, puis de joindre les tables en faisant

163
00:07:47,320 --> 00:07:50,250
‫référence au champ ID de la table des commentaires.

164
00:07:50,250 --> 00:07:52,590
‫Maintenant, nous n'allons pas utiliser de bases de

165
00:07:52,590 --> 00:07:55,460
‫données relationnelles dans ce cours, mais je pense qu'il est

166
00:07:55,460 --> 00:07:57,510
‫toujours important de connaître les différences

167
00:07:57,510 --> 00:07:59,630
‫si vous voulez devenir un bon développeur back-end.

168
00:07:59,630 --> 00:08:01,940
‫Quoi qu'il en soit, et maintenant juste

169
00:08:01,940 --> 00:08:04,810
‫pour finir, encore deux choses sur les documents BSON.

170
00:08:04,810 --> 00:08:07,510
‫Premièrement, la taille maximale de chaque

171
00:08:07,510 --> 00:08:12,120
‫document est actuellement de 16 Mo, mais cela pourrait augmenter à l'avenir.

172
00:08:12,120 --> 00:08:16,180
‫Et deuxièmement, chaque document contient un identifiant unique, qui

173
00:08:16,180 --> 00:08:19,900
‫agit comme une clé primaire de ce document.

174
00:08:19,900 --> 00:08:23,780
‫Il est automatiquement généré avec le type de données ID d'objet à chaque

175
00:08:23,780 --> 00:08:26,000
‫fois qu'il y a un nouveau document,

176
00:08:26,000 --> 00:08:28,605
‫et nous n'avons donc pas à nous en préoccuper.

177
00:08:28,605 --> 00:08:32,240
‫Très bien, et cela devrait être un aperçu assez bref pour

178
00:08:32,240 --> 00:08:33,610
‫nous permettre de

179
00:08:33,610 --> 00:08:37,210
‫démarrer et d'utiliser réellement MongoDB à partir de la prochaine conférence.

180
00:08:37,210 --> 00:08:38,873
‫Alors, passons maintenant.

