1
00:00:01,180 --> 00:00:02,990
‫Narrateur : L'une des étapes

2
00:00:02,990 --> 00:00:06,250
‫les plus importantes dans la création d'applications gourmandes en données

3
00:00:06,250 --> 00:00:08,700
‫consiste à modéliser toutes ces données dans MongoDB.

4
00:00:08,700 --> 00:00:12,300
‫Et c'est ce dont nous allons parler dans cette conférence.

5
00:00:12,300 --> 00:00:14,710
‫Il est donc vraiment crucial que vous

6
00:00:14,710 --> 00:00:19,710
‫le suiviez, même au début, c'est beaucoup à assimiler. D'accord.

7
00:00:19,810 --> 00:00:22,013
‫Quoi qu'il en soit, commençons maintenant.

8
00:00:23,530 --> 00:00:27,530
‫Maintenant, la modélisation des données est probablement un concept très nouveau pour vous.

9
00:00:27,530 --> 00:00:28,920
‫Alors avant de commencer

10
00:00:28,920 --> 00:00:32,070
‫; permet de clarifier de quoi nous allons réellement parler.

11
00:00:32,070 --> 00:00:35,656
‫Ainsi, la modélisation des données est le processus consistant à prendre des

12
00:00:35,656 --> 00:00:38,770
‫données non structurées générées par un scénario du monde réel,

13
00:00:38,770 --> 00:00:42,090
‫puis à les structurer en un modèle de données logique dans

14
00:00:42,090 --> 00:00:43,410
‫une base de données.

15
00:00:43,410 --> 00:00:46,300
‫Et nous le faisons selon un ensemble

16
00:00:46,300 --> 00:00:49,330
‫de critères que nous allons découvrir dans cette vidéo.

17
00:00:49,330 --> 00:00:51,980
‫Par exemple; disons que nous voulons concevoir un modèle

18
00:00:51,980 --> 00:00:54,120
‫de données de boutique en ligne.

19
00:00:54,120 --> 00:00:57,040
‫Il y aura initialement une tonne de données non structurées dont nous savons

20
00:00:57,040 --> 00:00:58,130
‫que nous avons besoin.

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

22
00:00:58,980 --> 00:01:00,900
‫Des trucs comme des produits, des

23
00:01:00,900 --> 00:01:03,875
‫catégories, des commandes de clients, des paniers d'achat, des fournisseurs.

24
00:01:03,875 --> 00:01:06,300
‫Et ainsi de suite.

25
00:01:06,300 --> 00:01:09,240
‫Notre objectif avec la modélisation des données est ensuite de

26
00:01:09,240 --> 00:01:11,450
‫structurer ces données de manière logique.

27
00:01:11,450 --> 00:01:14,090
‫Reflétant les relations réelles qui existent

28
00:01:14,090 --> 00:01:16,920
‫entre certains de ces ensembles de données.

29
00:01:16,920 --> 00:01:19,670
‫Un peu comme vous pouvez le voir dans cet exemple.

30
00:01:19,670 --> 00:01:23,110
‫Et ce n'est bien sûr qu'une sorte de situation imaginaire mais

31
00:01:23,110 --> 00:01:24,320
‫vous voyez l'idée.

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

33
00:01:25,600 --> 00:01:28,940
‫Maintenant, de nombreux développeurs backend disent que la modélisation des données est

34
00:01:28,940 --> 00:01:30,930
‫l'endroit où nous devons le plus réfléchir.

35
00:01:30,930 --> 00:01:33,670
‫C'est la partie la plus exigeante de la

36
00:01:33,670 --> 00:01:35,310
‫création d'une application entière.

37
00:01:35,310 --> 00:01:38,100
‫Parce que ce n'est vraiment pas toujours simple.

38
00:01:38,100 --> 00:01:41,070
‫Et parfois, il n'y a tout simplement pas de bonnes réponses.

39
00:01:41,070 --> 00:01:45,500
‫Il ne s'agit donc pas d'une seule manière correcte et unique de structurer les données.

40
00:01:45,500 --> 00:01:48,420
‫Mais de toute façon, je ferai de mon mieux pour expliquer le

41
00:01:48,420 --> 00:01:49,510
‫processus dans cette vidéo.

42
00:01:49,510 --> 00:01:52,367
‫Et pour cela, nous allons passer par quatre étapes.

43
00:01:52,367 --> 00:01:56,200
‫Donc dans la première étape; nous avons appris à identifier

44
00:01:56,200 --> 00:01:59,340
‫différents types de relations entre les données.

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

46
00:02:00,360 --> 00:02:03,019
‫nous allons comprendre la différence entre

47
00:02:03,019 --> 00:02:07,163
‫le référencement ou la normalisation et l'intégration ou la dénormalisation.

48
00:02:07,163 --> 00:02:09,030
‫Dans l'étape suivante et

49
00:02:09,030 --> 00:02:11,660
‫la plus importante ; Je vais vous montrer

50
00:02:11,660 --> 00:02:13,560
‫mon cadre pour décider si nous

51
00:02:13,560 --> 00:02:15,750
‫devons intégrer des documents ou faire référence

52
00:02:15,750 --> 00:02:18,690
‫à d'autres documents en fonction de plusieurs facteurs différents.

53
00:02:18,690 --> 00:02:20,810
‫Aussi, il faut parler rapidement des

54
00:02:20,810 --> 00:02:22,680
‫différents types de référencement.

55
00:02:22,680 --> 00:02:25,920
‫Parce que c'est important si c'est le type de conception

56
00:02:25,920 --> 00:02:28,220
‫que nous choisissons pour nos données.

57
00:02:28,220 --> 00:02:32,290
‫Ce sera donc en fait un cours assez théorique.

58
00:02:32,290 --> 00:02:35,940
‫Mais aussi un élément absolument essentiel pour votre progression en

59
00:02:35,940 --> 00:02:37,660
‫tant que développeur back-end.

60
00:02:37,660 --> 00:02:41,553
‫Parce que la façon dont nous concevons les données et la façon dont

61
00:02:41,553 --> 00:02:45,180
‫nous modélisons nos données peut faire ou défaire toute notre application.

62
00:02:45,180 --> 00:02:47,950
‫Et il y aura beaucoup d'exemples en cours de route pour

63
00:02:47,950 --> 00:02:49,510
‫rendre ce processus plus facile.

64
00:02:49,510 --> 00:02:50,343
‫D'accord.

65
00:02:51,320 --> 00:02:53,440
‫Et la première chose dont nous

66
00:02:53,440 --> 00:02:55,780
‫allons parler, ce sont les différents types

67
00:02:55,780 --> 00:02:58,210
‫de relations qui peuvent exister entre les données.

68
00:02:58,210 --> 00:03:00,780
‫Il existe donc trois grands types de relations.

69
00:03:00,780 --> 00:03:05,150
‫Un à un, un à plusieurs et plusieurs à plusieurs.

70
00:03:05,150 --> 00:03:06,990
‫Et je vais utiliser une application

71
00:03:06,990 --> 00:03:08,890
‫de film comme exemple dans cette diapositive.

72
00:03:08,890 --> 00:03:10,000
‫D'accord?

73
00:03:10,000 --> 00:03:12,440
‫Donc, d'abord, une relation un à un

74
00:03:12,440 --> 00:03:14,140
‫entre les données est

75
00:03:14,140 --> 00:03:17,370
‫fondamentalement lorsqu'un champ ne peut avoir qu'une seule valeur.

76
00:03:17,370 --> 00:03:21,550
‫Donc, dans notre exemple d'application de film ; un film n'a

77
00:03:21,550 --> 00:03:22,990
‫qu'un seul nom.

78
00:03:22,990 --> 00:03:24,910
‫Et c'est donc un exemple

79
00:03:24,910 --> 00:03:27,160
‫simple d'une relation un à un.

80
00:03:27,160 --> 00:03:29,690
‫Mais ces relations ne sont pas vraiment importantes en

81
00:03:29,690 --> 00:03:31,363
‫termes de modélisation des données.

82
00:03:32,330 --> 00:03:34,430
‫Maintenant, les relations les

83
00:03:34,430 --> 00:03:37,210
‫plus importantes sont celles d'un à plusieurs.

84
00:03:37,210 --> 00:03:39,770
‫Et ils sont si importants que dans

85
00:03:39,770 --> 00:03:42,510
‫MongoDB, nous distinguons en fait trois types de

86
00:03:42,510 --> 00:03:44,540
‫relations un à plusieurs.

87
00:03:44,540 --> 00:03:49,540
‫Un à quelques-uns, un à plusieurs, et un à une tonne ou à un million ou

88
00:03:49,910 --> 00:03:53,230
‫quelque chose comme ça. Donc, la différence ici est

89
00:03:53,230 --> 00:03:56,893
‫basée sur le montant relatif du nombre. D'accord.

90
00:03:57,840 --> 00:04:00,969
‫Ainsi, un exemple de relation individuelle

91
00:04:00,969 --> 00:04:05,967
‫est qu'un film peut remporter de nombreux prix, mais en réalité quelques-uns.

92
00:04:05,967 --> 00:04:09,630
‫Donc le film ne va pas gagner mille récompenses mais

93
00:04:09,630 --> 00:04:11,220
‫il peut en gagner.

94
00:04:11,220 --> 00:04:14,930
‫Et c'est donc une relation typique d'un à quelques-uns.

95
00:04:14,930 --> 00:04:18,710
‫Vous voyez donc qu'en général, une relation un à

96
00:04:18,710 --> 00:04:23,210
‫plusieurs signifie qu'un document peut être lié à de nombreux autres documents.

97
00:04:23,210 --> 00:04:26,680
‫Cela peut sembler un peu abstrait sans les données JSON, mais c'est

98
00:04:26,680 --> 00:04:28,480
‫en fait le but ici.

99
00:04:28,480 --> 00:04:31,040
‫Je veux juste vous montrer un

100
00:04:31,040 --> 00:04:33,759
‫aperçu conceptuel de ces différents types de relations.

101
00:04:33,759 --> 00:04:36,872
‫Quoi qu'il en soit, n'importe quelle relation un à

102
00:04:36,872 --> 00:04:40,600
‫plusieurs, un document peut se rapporter à des centaines ou des

103
00:04:40,600 --> 00:04:42,070
‫milliers d'autres documents.

104
00:04:42,070 --> 00:04:44,788
‫Par exemple; un film peut avoir des milliers

105
00:04:44,788 --> 00:04:46,710
‫de critiques dans notre application.

106
00:04:46,710 --> 00:04:49,380
‫Et donc ce n'est pas vraiment une relation un à quelques

107
00:04:49,380 --> 00:04:51,524
‫mais un à plusieurs. D'accord?

108
00:04:51,524 --> 00:04:55,616
‫Et enfin, nous avons la relation un à tonne.

109
00:04:55,616 --> 00:04:59,720
‫Imaginez que nous voulions implémenter une fonctionnalité de journalisation

110
00:04:59,720 --> 00:05:03,110
‫dans notre application. Donc en gros pour savoir exactement

111
00:05:03,110 --> 00:05:04,870
‫ce qui se passe sur notre serveur.

112
00:05:04,870 --> 00:05:08,770
‫Ces journaux peuvent alors facilement atteindre des millions de documents.

113
00:05:08,770 --> 00:05:11,270
‫Et c'est donc un exemple

114
00:05:11,270 --> 00:05:14,200
‫très typique d'une relation entre deux personnes.

115
00:05:14,200 --> 00:05:17,100
‫Et la différence entre plusieurs et une tonne est

116
00:05:17,100 --> 00:05:20,730
‫bien sûr un peu floue, mais pensez simplement que si quelque chose

117
00:05:20,730 --> 00:05:23,360
‫peut croître presque à l'infini, alors c'est certainement

118
00:05:23,360 --> 00:05:25,532
‫une relation d'un à une tonne.

119
00:05:25,532 --> 00:05:28,763
‫Encore une fois, les relations un à plusieurs

120
00:05:28,763 --> 00:05:31,650
‫sont les plus importantes à connaître.

121
00:05:31,650 --> 00:05:34,050
‫D'ailleurs; dans les bases de

122
00:05:34,050 --> 00:05:37,061
‫données relationnelles, il n'y en a qu'un pour

123
00:05:37,061 --> 00:05:39,800
‫plusieurs sans quantifier combien cela représente réellement.

124
00:05:39,800 --> 00:05:41,800
‫Dans les bases de données

125
00:05:41,800 --> 00:05:44,010
‫MongoDB, c'est une différence extrêmement importante.

126
00:05:44,010 --> 00:05:47,150
‫Parce que c'est l'un des facteurs que nous allons utiliser

127
00:05:47,150 --> 00:05:49,891
‫pour décider si nous devons dénormaliser ou

128
00:05:49,891 --> 00:05:53,340
‫normaliser les données, comme vous l'apprendrez un peu plus tard.

129
00:05:53,340 --> 00:05:57,181
‫Quoi qu'il en soit, le moins type de relation est le plusieurs

130
00:05:57,181 --> 00:06:00,149
‫à plusieurs où un film peut avoir plusieurs acteurs.

131
00:06:00,149 --> 00:06:04,876
‫Mais en même temps, un acteur peut jouer dans de nombreux films.

132
00:06:04,876 --> 00:06:07,910
‫Et donc ici, la relation va essentiellement dans

133
00:06:07,910 --> 00:06:09,630
‫les deux sens.

134
00:06:09,630 --> 00:06:11,800
‫Là où auparavant dans les autres types,

135
00:06:11,800 --> 00:06:13,939
‫ce n'était que dans un sens.

136
00:06:13,939 --> 00:06:17,470
‫Par exemple, un film peut avoir plusieurs critiques, mais une

137
00:06:17,470 --> 00:06:22,450
‫en particulier ne concerne que ce film. Droit.

138
00:06:22,450 --> 00:06:24,560
‫Et il en va de même pour les récompenses.

139
00:06:24,560 --> 00:06:27,506
‫Ainsi, un prix spécifique, comme celui du meilleur

140
00:06:27,506 --> 00:06:30,914
‫acteur, est attribué à un seul film et non à plusieurs.

141
00:06:30,914 --> 00:06:35,580
‫Mais avec les films et les acteurs, c'est effectivement différent.

142
00:06:35,580 --> 00:06:39,250
‫Encore une fois, un film met en vedette de nombreux acteurs,

143
00:06:39,250 --> 00:06:41,920
‫mais un acteur joue de nombreux

144
00:06:41,920 --> 00:06:45,020
‫films et c'est donc une relation plusieurs à plusieurs.

145
00:06:45,020 --> 00:06:46,170
‫D'accord.

146
00:06:46,170 --> 00:06:49,060
‫Gardez donc tout cela à l'esprit alors que nous avançons maintenant

147
00:06:49,060 --> 00:06:50,063
‫dans cette conférence.

148
00:06:51,760 --> 00:06:54,870
‫Et probablement l'aspect le plus important que nous devons apprendre

149
00:06:54,870 --> 00:06:57,900
‫sur les bases de données MongoDB est le référencement

150
00:06:57,900 --> 00:07:00,340
‫et l'intégration de deux ensembles de données.

151
00:07:00,340 --> 00:07:02,350
‫Et en fait, nous en

152
00:07:02,350 --> 00:07:05,050
‫avons déjà parlé un peu auparavant, mais passons en

153
00:07:05,050 --> 00:07:07,311
‫revue ici et approfondissons également un peu.

154
00:07:07,311 --> 00:07:09,962
‫Ainsi, chaque fois que nous avons deux

155
00:07:09,962 --> 00:07:13,829
‫ensembles de données liés, nous pouvons soit représenter ces données liées

156
00:07:13,829 --> 00:07:18,829
‫sous une forme de référence ou normalisée, soit sous une forme intégrée ou dénormalisée.

157
00:07:18,842 --> 00:07:22,190
‫Et je continue à utiliser les deux termes liés ensemble, comme

158
00:07:22,190 --> 00:07:24,340
‫référencement et normalisation, car vous les verrez

159
00:07:24,340 --> 00:07:26,460
‫tous les deux utilisés et

160
00:07:26,460 --> 00:07:29,510
‫il est donc important que vous les connaissiez tous.

161
00:07:29,510 --> 00:07:33,070
‫Quoi qu'il en soit, dans le formulaire référencé, nous gardons deux ensembles

162
00:07:33,070 --> 00:07:35,826
‫de données liés et tous les documents séparés.

163
00:07:35,826 --> 00:07:39,589
‫Encore une fois, toutes les données sont bien séparées, ce

164
00:07:39,589 --> 00:07:43,275
‫qui est exactement ce que signifie la normalisation.

165
00:07:43,275 --> 00:07:47,110
‫Donc, en continuant, l'exemple de base de données de films

166
00:07:47,110 --> 00:07:50,750
‫d'avant nous aurions un document de film et un

167
00:07:50,750 --> 00:07:54,870
‫document d'acteur pour chaque acteur. Maintenant, comment ferions-nous alors le lien

168
00:07:54,870 --> 00:07:58,710
‫entre le film et les acteurs afin que plus tard dans notre application,

169
00:07:58,710 --> 00:08:02,150
‫nous puissions montrer quels acteurs ont joué dans un film particulier.

170
00:08:02,150 --> 00:08:05,210
‫Parce que s'ils sont tous complètement différents, le film n'a

171
00:08:05,210 --> 00:08:09,438
‫aucun moyen de connaître les acteurs. Droit.

172
00:08:09,438 --> 00:08:12,253
‫Eh bien, c'est là qu'interviennent les identifiants.

173
00:08:12,253 --> 00:08:16,460
‫Nous utilisons donc les identifiants des acteurs afin de créer des références sur

174
00:08:16,460 --> 00:08:18,020
‫le document du film.

175
00:08:18,020 --> 00:08:20,981
‫Connecter efficacement les films avec les acteurs.

176
00:08:20,981 --> 00:08:24,760
‫Ainsi, vous voyez que dans un document de film, nous avons un tableau

177
00:08:24,760 --> 00:08:27,198
‫dans lequel nous stockons les identifiants de tous

178
00:08:27,198 --> 00:08:30,760
‫les acteurs afin que lorsque nous demandons des données sur un certain film,

179
00:08:30,760 --> 00:08:34,553
‫nous puissions facilement identifier ses acteurs. Cela a-t-il du sens?

180
00:08:34,553 --> 00:08:38,830
‫Maintenant, ce type de référencement est appelé référencement enfant car c'est

181
00:08:38,830 --> 00:08:41,480
‫le parent dans ce cas le film

182
00:08:41,480 --> 00:08:45,104
‫qui référence ses enfants. Dans ce cas, les acteurs.

183
00:08:45,104 --> 00:08:48,841
‫Donc, nous créons vraiment une sorte de hiérarchie ici. Droit.

184
00:08:48,841 --> 00:08:51,870
‫Maintenant, il y a aussi le référencement parental et

185
00:08:51,870 --> 00:08:54,390
‫nous en reparlerons un peu plus tard.

186
00:08:54,390 --> 00:08:58,710
‫Et au passage dans les bases de données relationnelles ; toutes les données

187
00:08:58,710 --> 00:09:01,958
‫sont toujours représentées sous une forme normalisée comme celle-ci.

188
00:09:01,958 --> 00:09:05,490
‫Mais dans une base de données sans suite

189
00:09:05,490 --> 00:09:09,700
‫comme MongoDB, nous pouvons dénormaliser les données sous une forme

190
00:09:09,700 --> 00:09:12,450
‫dénormalisée simplement en incorporant le

191
00:09:12,450 --> 00:09:15,330
‫document associé directement dans le document principal.

192
00:09:15,330 --> 00:09:18,330
‫Alors maintenant, nous avons toutes les données

193
00:09:18,330 --> 00:09:22,060
‫pertinentes sur les acteurs directement dans un document principal du film

194
00:09:22,060 --> 00:09:25,700
‫sans avoir besoin de documents, de collections et d'identifiants séparés.

195
00:09:25,700 --> 00:09:30,088
‫Encore une fois, si nous choisissons de dénormaliser ou d'intégrer nos données,

196
00:09:30,088 --> 00:09:34,280
‫nous aurons un document principal contenant toutes les données principales ainsi que

197
00:09:34,280 --> 00:09:37,197
‫les données associées. D'accord.

198
00:09:37,197 --> 00:09:40,340
‫Et le résultat de ceci est que notre application aura besoin

199
00:09:40,340 --> 00:09:43,330
‫de moins de requêtes dans la base de données.

200
00:09:43,330 --> 00:09:45,000
‫Parce que nous pouvons

201
00:09:45,000 --> 00:09:48,074
‫obtenir toutes les données sur les films et les

202
00:09:48,074 --> 00:09:51,650
‫acteurs en même temps, ce qui augmentera bien sûr nos performances.

203
00:09:51,650 --> 00:09:53,840
‫Maintenant, l'inconvénient ici est bien sûr

204
00:09:53,840 --> 00:09:57,530
‫que nous ne pouvons pas vraiment interroger les données intégrées par elles-mêmes.

205
00:09:57,530 --> 00:10:00,810
‫Et donc si c'est une exigence pour l'application, vous

206
00:10:00,810 --> 00:10:03,790
‫devrez choisir une conception normalisée et puisque nous

207
00:10:03,790 --> 00:10:06,280
‫parlons des avantages et des inconvénients

208
00:10:06,280 --> 00:10:09,030
‫de la forme dénormalisée ; faisons de

209
00:10:09,030 --> 00:10:11,490
‫même pour la conception normalisée.

210
00:10:11,490 --> 00:10:13,920
‫Et fondamentalement, c'est un peu le contraire de

211
00:10:13,920 --> 00:10:15,770
‫ce dont nous venons de parler.

212
00:10:15,770 --> 00:10:18,319
‫Il y a donc une amélioration des

213
00:10:18,319 --> 00:10:22,390
‫performances lorsque nous devons souvent interroger les données associées par nous-mêmes, car nous

214
00:10:22,390 --> 00:10:25,740
‫pouvons alors simplement interroger les données dont nous avons besoin et

215
00:10:25,740 --> 00:10:28,490
‫pas toujours les films et les acteurs ensemble.

216
00:10:28,490 --> 00:10:31,640
‫Mais d'autre part; lorsque nous devons réellement interroger des films et

217
00:10:31,640 --> 00:10:33,906
‫des acteurs ensemble, nous aurons alors besoin

218
00:10:33,906 --> 00:10:36,396
‫de nombreuses requêtes dans la base de données.

219
00:10:36,396 --> 00:10:40,010
‫Donc, d'abord la requête pour le film, puis à partir de là,

220
00:10:40,010 --> 00:10:42,610
‫nous aurons également besoin d'une requête pour l'acteur et

221
00:10:42,610 --> 00:10:44,989
‫cela fonctionne bien sûr pour la performance.

222
00:10:44,989 --> 00:10:48,328
‫Ainsi, lors de la conception de votre base de données ; c'est le genre de choses que

223
00:10:48,328 --> 00:10:50,569
‫vous devez garder à l'esprit. D'accord.

224
00:10:50,569 --> 00:10:54,900
‫Et maintenant juste comme note latérale ; nous pourrions bien sûr commencer notre processus

225
00:10:54,900 --> 00:10:56,994
‫de réflexion avec des données dénormalisées, puis

226
00:10:56,994 --> 00:10:59,670
‫en arriver à la conclusion qu'il est préférable

227
00:10:59,670 --> 00:11:01,692
‫de normaliser réellement les données.

228
00:11:01,692 --> 00:11:05,043
‫Ainsi, lorsque l'on pense à notre modèle de données, cette façon

229
00:11:05,043 --> 00:11:08,378
‫d'organiser les données fonctionne bien sûr dans les deux sens.

230
00:11:08,378 --> 00:11:12,570
‫Maintenant, comment décidons-nous réellement si nous devons normaliser

231
00:11:12,570 --> 00:11:15,330
‫ou dénormaliser les données ?

232
00:11:15,330 --> 00:11:18,033
‫Eh bien, c'est exactement ce que nous allons apprendre ensuite.

233
00:11:19,690 --> 00:11:22,974
‫Ainsi, lorsque nous avons deux ensembles de données liés ; nous devons

234
00:11:22,974 --> 00:11:26,180
‫décider si nous allons intégrer les ensembles de données ou si

235
00:11:26,180 --> 00:11:27,693
‫nous allons les garder séparés

236
00:11:27,693 --> 00:11:30,400
‫et les référencer d'un ensemble de données à l'autre.

237
00:11:30,400 --> 00:11:32,730
‫Et j'ai en quelque sorte développé ce cadre

238
00:11:32,730 --> 00:11:36,070
‫de décision que je vais vous montrer où nous utilisons trois

239
00:11:36,070 --> 00:11:37,770
‫critères pour prendre cette décision.

240
00:11:37,770 --> 00:11:40,450
‫Tout d'abord, nous examinons le type de relations

241
00:11:40,450 --> 00:11:42,800
‫qui existent entre les ensembles de données.

242
00:11:42,800 --> 00:11:45,856
‫Deuxièmement, nous essayons de déterminer le modèle d'accès

243
00:11:45,856 --> 00:11:50,150
‫aux données de l'ensemble de données que nous voulons intégrer ou référencer.

244
00:11:50,150 --> 00:11:53,320
‫Et cela signifie simplement analyser la fréquence à laquelle les données sont lues

245
00:11:53,320 --> 00:11:55,282
‫et écrites dans cet ensemble de données.

246
00:11:55,282 --> 00:11:59,025
‫Ensuite, nous examinons également quelque chose que j'appelle la proximité des données.

247
00:11:59,025 --> 00:12:02,940
‫Et la proximité des données est un terme que je viens d'inventer, mais

248
00:12:02,940 --> 00:12:06,870
‫cela signifie à quel point les données sont vraiment liées et comment nous

249
00:12:06,870 --> 00:12:10,109
‫voulons interroger les données de la base de données.

250
00:12:10,109 --> 00:12:11,850
‫Et cela aura plus de

251
00:12:11,850 --> 00:12:14,180
‫sens lorsque nous en parlerons dans un instant.

252
00:12:14,180 --> 00:12:17,330
‫Maintenant, prendre réellement la décision ; nous devons combiner

253
00:12:17,330 --> 00:12:19,350
‫tous ces trois critères

254
00:12:19,350 --> 00:12:21,792
‫et ne pas utiliser l'un d'eux isolément.

255
00:12:21,792 --> 00:12:25,230
‫Ainsi par exemple ; ce n'est pas parce que le critère

256
00:12:25,230 --> 00:12:28,380
‫numéro un dit d'intégrer cela que nous n'avons pas besoin

257
00:12:28,380 --> 00:12:30,425
‫d'examiner les deux autres critères.

258
00:12:30,425 --> 00:12:34,124
‫Très bien et commençons par le type de relation.

259
00:12:34,124 --> 00:12:37,968
‫Ainsi, généralement, lorsque nous avons une ou plusieurs relations, nous intégrons

260
00:12:37,968 --> 00:12:40,700
‫toujours l'ensemble de données associé dans l'ensemble de

261
00:12:40,700 --> 00:12:43,430
‫données principal, comme nous l'avons appris dans

262
00:12:43,430 --> 00:12:45,860
‫la dernière diapositive. Droit.

263
00:12:45,860 --> 00:12:49,110
‫Maintenant dans une relation un à plusieurs ; les choses

264
00:12:49,110 --> 00:12:52,880
‫sont un peu plus floues, il est donc possible d'intégrer ou de référencer.

265
00:12:52,880 --> 00:12:55,140
‫Dans ce cas, nous devrons décider

266
00:12:55,140 --> 00:12:57,304
‫selon les deux autres critères.

267
00:12:57,304 --> 00:12:59,825
‫D'un autre côté, sur une relation

268
00:12:59,825 --> 00:13:03,894
‫un à une tonne ou plusieurs à plusieurs, nous référençons généralement

269
00:13:03,894 --> 00:13:06,811
‫toujours les données. C'est parce que si nous

270
00:13:06,811 --> 00:13:10,004
‫intégrions réellement dans ce cas, nous pourrions rapidement créer un document beaucoup trop volumineux.

271
00:13:10,004 --> 00:13:14,902
‫Dépassant même potentiellement le maximum de 16 mégaoctets.

272
00:13:14,902 --> 00:13:18,214
‫Et donc la solution pour cela est bien sûr de référencer

273
00:13:18,214 --> 00:13:22,090
‫ou de normaliser les données. Et comme exemple rapide ;

274
00:13:22,090 --> 00:13:24,142
‫disons que dans notre exemple de base

275
00:13:24,142 --> 00:13:27,830
‫de données de films, nous avons environ 100 images associées à chaque film.

276
00:13:27,830 --> 00:13:30,874
‫Nous pourrions donc dire que c'est une relation un

277
00:13:30,874 --> 00:13:34,230
‫à plusieurs, mais allons-nous intégrer l'ensemble de données ou devrions-nous

278
00:13:34,230 --> 00:13:37,523
‫plutôt les référencer ici. Eh bien, nous ne savons pas vraiment.

279
00:13:37,523 --> 00:13:40,571
‫Jetons donc un œil aux deux autres critères.

280
00:13:40,571 --> 00:13:44,420
‫Ainsi, le second concerne les modèles d'accès aux données où il

281
00:13:44,420 --> 00:13:46,290
‫ne s'agit que d'une

282
00:13:46,290 --> 00:13:48,242
‫description sophistiquée pour évaluer si un

283
00:13:48,242 --> 00:13:51,559
‫certain ensemble de données est principalement écrit ou lu.

284
00:13:51,559 --> 00:13:55,760
‫Donc, si l'ensemble de données sur lequel nous décidons est principalement lu et

285
00:13:55,760 --> 00:13:58,179
‫que les données ne sont pas beaucoup

286
00:13:58,179 --> 00:14:01,620
‫mises à jour, nous devrions probablement intégrer cet ensemble de données.

287
00:14:01,620 --> 00:14:04,690
‫Ainsi, un rapport lecture/écriture élevé signifie simplement qu'il y

288
00:14:04,690 --> 00:14:07,100
‫a beaucoup plus de lecture que d'écriture.

289
00:14:07,100 --> 00:14:11,100
‫Et encore une fois, un ensemble de données comme celui-ci est un bon candidat

290
00:14:11,100 --> 00:14:11,983
‫pour l'intégration.

291
00:14:12,830 --> 00:14:15,980
‫La raison en est qu'en imbriquant, nous n'avons besoin que d'un seul

292
00:14:15,980 --> 00:14:18,379
‫déplacement dans la base de données par requête.

293
00:14:18,379 --> 00:14:22,197
‫Alors que pour le référencement nous avons besoin de deux voyages. Droit.

294
00:14:22,197 --> 00:14:25,660
‫Donc, si nous intégrons des données qui sont beaucoup lues ;

295
00:14:25,660 --> 00:14:28,383
‫à chaque requête, nous économisons un voyage vers

296
00:14:28,383 --> 00:14:32,147
‫la base de données, ce qui rend l'ensemble du processus plus performant.

297
00:14:32,147 --> 00:14:35,260
‫Je pense donc que notre exemple d'image de film

298
00:14:35,260 --> 00:14:38,320
‫serait en fait un bon candidat pour l'intégration.

299
00:14:38,320 --> 00:14:41,543
‫Car une fois que les 100 images sont enregistrées dans la base

300
00:14:41,543 --> 00:14:43,920
‫de données, elles ne sont plus vraiment mises

301
00:14:43,920 --> 00:14:46,930
‫à jour car il n'y a vraiment rien à mettre

302
00:14:46,930 --> 00:14:50,057
‫à jour sur une image. D'accord, donc tout est

303
00:14:50,057 --> 00:14:52,563
‫question de lecture et donc sur la

304
00:14:52,563 --> 00:14:55,501
‫base de ce critère, nous intégrerions les documents imagés.

305
00:14:55,501 --> 00:14:59,092
‫D'un autre côté, si nos données sont beaucoup mises

306
00:14:59,092 --> 00:15:03,118
‫à jour, nous devrions envisager de référencer ou de normaliser les données.

307
00:15:03,118 --> 00:15:06,700
‫C'est parce que c'est plus de travail pour le moteur de base

308
00:15:06,700 --> 00:15:08,870
‫de données pour mettre à jour

309
00:15:08,870 --> 00:15:11,600
‫et incorporer un document qu'un document autonome plus simple.

310
00:15:11,600 --> 00:15:13,980
‫Et puisque notre objectif principal est la performance ;

311
00:15:13,980 --> 00:15:15,917
‫nous normalisons simplement l'ensemble de données.

312
00:15:15,917 --> 00:15:19,653
‫Dans notre exemple, disons que chaque film a de nombreuses critiques et

313
00:15:19,653 --> 00:15:23,284
‫que chaque critique peut être marquée comme utile par l'utilisateur.

314
00:15:23,284 --> 00:15:27,560
‫Ainsi, chaque fois que quelqu'un clique sur cet avis, cela a été utile

315
00:15:27,560 --> 00:15:29,780
‫dans notre application. Nous devons

316
00:15:29,780 --> 00:15:31,740
‫mettre à jour le document correspondant.

317
00:15:31,740 --> 00:15:35,030
‫Et cela signifie que les données peuvent changer tout

318
00:15:35,030 --> 00:15:38,520
‫le temps et c'est donc un excellent candidat pour la normalisation.

319
00:15:38,520 --> 00:15:41,420
‫Encore une fois parce que nous ne voulons pas interroger les films

320
00:15:41,420 --> 00:15:45,190
‫tout le temps si tout ce que nous voulons vraiment mettre à jour, ce sont

321
00:15:45,190 --> 00:15:47,230
‫les critiques en les marquant comme utiles.

322
00:15:47,230 --> 00:15:49,464
‫D'accord, est-ce que ça a du sens ?

323
00:15:49,464 --> 00:15:53,500
‫Et enfin le dernier critère que j'appelle la proximité des données ;

324
00:15:53,500 --> 00:15:56,320
‫qui est juste comme une mesure pour combien

325
00:15:56,320 --> 00:15:59,469
‫les données sont liées. Donc, si les

326
00:15:59,469 --> 00:16:02,890
‫deux ensembles de données appartiennent vraiment intrinsèquement, ils

327
00:16:02,890 --> 00:16:05,880
‫devraient probablement être intégrés l'un dans l'autre.

328
00:16:05,880 --> 00:16:10,440
‫Dans notre exemple ; tous les utilisateurs peuvent avoir plusieurs adresses e-mail

329
00:16:10,440 --> 00:16:13,780
‫sur leur compte et puisqu'ils sont intrinsèquement connectés

330
00:16:13,780 --> 00:16:17,190
‫à l'utilisateur, il ne fait aucun doute que les

331
00:16:17,190 --> 00:16:19,920
‫e-mails doivent être intégrés au document.

332
00:16:19,920 --> 00:16:23,830
‫Maintenant, si nous devons fréquemment interroger les deux ensembles de données,

333
00:16:23,830 --> 00:16:26,388
‫c'est une très bonne raison de

334
00:16:26,388 --> 00:16:29,696
‫normaliser les données en deux ensembles de données distincts.

335
00:16:29,696 --> 00:16:32,790
‫Même s'ils sont étroitement liés.

336
00:16:32,790 --> 00:16:35,227
‫Imaginez donc que dans notre application,

337
00:16:35,227 --> 00:16:40,227
‫nous avons un quiz où les utilisateurs doivent identifier un film à partir d'images.

338
00:16:40,440 --> 00:16:43,080
‫Cela signifie que nous allons interroger beaucoup d'images

339
00:16:43,080 --> 00:16:44,180
‫par elles-mêmes.

340
00:16:44,180 --> 00:16:47,756
‫Donc sans nécessairement interroger les films eux-mêmes.

341
00:16:47,756 --> 00:16:50,640
‫Et donc si on applique ce troisième critère ;

342
00:16:50,640 --> 00:16:54,137
‫nous arrivons à la conclusion que nous devrions réellement normaliser l'ensemble

343
00:16:54,137 --> 00:16:56,759
‫de données d'image. D'accord.

344
00:16:56,759 --> 00:17:00,770
‫Car encore une fois, si nous implémentons cette fonctionnalité de quiz ;

345
00:17:00,770 --> 00:17:04,057
‫les images vont être interrogées d'elles-mêmes tout le temps.

346
00:17:04,057 --> 00:17:07,422
‫Donc, tout cela montre que nous devrions vraiment

347
00:17:07,422 --> 00:17:09,850
‫examiner les trois critères ensemble

348
00:17:09,850 --> 00:17:12,700
‫plutôt que l'un d'entre eux isolément.

349
00:17:12,700 --> 00:17:15,841
‫Parce que cela pourrait conduire à des décisions moins optimales.

350
00:17:15,841 --> 00:17:18,908
‫Et je dis moins optimale au lieu de fausse

351
00:17:18,908 --> 00:17:21,766
‫car ce ne sont pas vraiment des

352
00:17:21,766 --> 00:17:25,262
‫manières totalement correctes ou totalement fausses de modéliser nos données.

353
00:17:25,262 --> 00:17:28,970
‫Il n'y a pas de règles strictes ; ce sont juste des directives

354
00:17:28,970 --> 00:17:31,380
‫que vous pouvez suivre pour trouver la

355
00:17:31,380 --> 00:17:33,860
‫manière probablement la plus correcte de structurer vos données.

356
00:17:33,860 --> 00:17:37,077
‫Mais encore une fois, il est difficile de se tromper vraiment.

357
00:17:37,077 --> 00:17:38,253
‫D'accord?

358
00:17:39,740 --> 00:17:43,110
‫Maintenant, disons que nous avons choisi de normaliser nos

359
00:17:43,110 --> 00:17:44,270
‫jeux de données.

360
00:17:44,270 --> 00:17:46,653
‫Donc en d'autres termes pour référencer des données.

361
00:17:46,653 --> 00:17:49,380
‫Puis après il faut encore

362
00:17:49,380 --> 00:17:52,840
‫choisir entre trois types de référencement différents.

363
00:17:52,840 --> 00:17:55,460
‫Référencement enfant, référencement parent

364
00:17:55,460 --> 00:17:57,540
‫et référencement bidirectionnel.

365
00:17:57,540 --> 00:18:00,767
‫Le premier type est donc le référencement enfant.

366
00:18:00,767 --> 00:18:04,440
‫Quel est le type de référencement que je vous ai déjà montré auparavant.

367
00:18:04,440 --> 00:18:05,470
‫D'accord?

368
00:18:05,470 --> 00:18:07,850
‫Et ne prenons pas l'exemple de journalisation des erreurs que

369
00:18:07,850 --> 00:18:10,128
‫j'ai mentionné plus tôt. Où nous

370
00:18:10,128 --> 00:18:13,021
‫pourrions potentiellement avoir des millions de documents verrouillés.

371
00:18:13,021 --> 00:18:17,300
‫Donc, dans le référencement des enfants ; nous conservons essentiellement les références

372
00:18:17,300 --> 00:18:20,460
‫aux documents enfants associés dans un document parent.

373
00:18:20,460 --> 00:18:22,941
‫Et ils sont généralement stockés dans un tableau.

374
00:18:22,941 --> 00:18:25,735
‫Vous voyez donc que chaque journal a un identifiant, puis

375
00:18:25,735 --> 00:18:29,040
‫dans le document de l'application, il y a ce tableau avec

376
00:18:29,040 --> 00:18:31,358
‫tous ces identifiants. Droit?

377
00:18:31,358 --> 00:18:34,400
‫Cependant, le problème ici est que

378
00:18:34,400 --> 00:18:39,320
‫ce tableau d'ID peut devenir très volumineux s'il y a beaucoup d'enfants.

379
00:18:39,320 --> 00:18:42,230
‫Et c'est un anti-modèle dans MongoDB.

380
00:18:42,230 --> 00:18:45,156
‫Donc quelque chose que nous devrions éviter à tout prix.

381
00:18:45,156 --> 00:18:47,660
‫De plus, le référencement des enfants fait

382
00:18:47,660 --> 00:18:51,410
‫en sorte que les parents et les enfants sont très étroitement liés.

383
00:18:51,410 --> 00:18:54,840
‫Ce qui n'est pas toujours idéal. Mais c'est exactement pourquoi

384
00:18:54,840 --> 00:18:57,020
‫nous avons le référencement des parents.

385
00:18:57,020 --> 00:19:00,300
‫Donc dans le référencement parent ; cela fonctionne en

386
00:19:00,300 --> 00:19:01,870
‫fait dans l'autre sens.

387
00:19:01,870 --> 00:19:05,570
‫Donc ici, dans chaque document enfant, nous gardons une

388
00:19:05,570 --> 00:19:07,430
‫référence à l'élément parent.

389
00:19:07,430 --> 00:19:10,267
‫D'où le nom parent de référencement.

390
00:19:10,267 --> 00:19:13,890
‫Dans cet exemple, l'ID d'application est 23 et donc

391
00:19:13,890 --> 00:19:16,640
‫dans chaque journal, il y a le

392
00:19:16,640 --> 00:19:18,990
‫champ d'application avec l'ID 23.

393
00:19:18,990 --> 00:19:21,660
‫Pour que l'enfant connaisse toujours son parent.

394
00:19:21,660 --> 00:19:24,920
‫Et donc dans ce cas, le parent ne sait

395
00:19:24,920 --> 00:19:26,080
‫rien des enfants.

396
00:19:26,080 --> 00:19:28,768
‫Ni qui ils sont ni combien ils sont.

397
00:19:28,768 --> 00:19:32,890
‫Ainsi, ils sont beaucoup plus isolés et plus autonomes.

398
00:19:32,890 --> 00:19:35,326
‫En cela, cela peut parfois être bénéfique.

399
00:19:35,326 --> 00:19:38,880
‫Alors, lequel de ces deux types est le meilleur pour

400
00:19:38,880 --> 00:19:40,527
‫cette relation de données.

401
00:19:40,527 --> 00:19:42,820
‫Et rappelez-vous comment j'ai dit qu'il pourrait y

402
00:19:42,820 --> 00:19:45,860
‫avoir des millions de journaux et supposons donc qu'il y ait

403
00:19:45,860 --> 00:19:47,652
‫deux millions de documents enregistrés.

404
00:19:47,652 --> 00:19:51,340
‫Dans un cas de référencement d'enfants, cela signifierait qu'il y

405
00:19:51,340 --> 00:19:53,209
‫a deux millions de

406
00:19:53,209 --> 00:19:55,091
‫références d'identification dans le document d'application.

407
00:19:55,091 --> 00:19:58,300
‫Droit? Maintenant, rappelez-vous également comment j'ai dit qu'il

408
00:19:58,300 --> 00:20:00,545
‫y a une limite de 16 mégaoctets sur les documents.

409
00:20:00,545 --> 00:20:04,302
‫Donc, si nous continuions à ajouter et à ajouter ces ID enfants

410
00:20:04,302 --> 00:20:06,716
‫dans le tableau sur le parent ; alors

411
00:20:06,716 --> 00:20:09,575
‫nous atteindrions assez rapidement cette limite de 16 mégaoctets

412
00:20:09,575 --> 00:20:11,772
‫que chaque document Bson peut contenir.

413
00:20:11,772 --> 00:20:14,702
‫Tout simplement parce que ce tableau va tellement grandir.

414
00:20:14,702 --> 00:20:17,210
‫Donc ça ne va pas vraiment marcher.

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

416
00:20:18,510 --> 00:20:20,590
‫D'un autre côté, avec le référencement

417
00:20:20,590 --> 00:20:22,990
‫des parents, ce problème ne se produira pas.

418
00:20:22,990 --> 00:20:25,570
‫Nous aurons simplement deux millions de

419
00:20:25,570 --> 00:20:30,540
‫documents verrouillés comme avant, mais chacun d'eux détient l'ID de son parent.

420
00:20:30,540 --> 00:20:33,098
‫Mais il n'y a pas de

421
00:20:33,098 --> 00:20:35,740
‫tableau qui grandira indéfiniment et donc le

422
00:20:35,740 --> 00:20:38,443
‫référencement parent serait la meilleure solution ici.

423
00:20:39,380 --> 00:20:41,901
‫Donc, la conclusion de tout cela est qu'en

424
00:20:41,901 --> 00:20:44,385
‫général, le référencement des enfants est mieux utilisé

425
00:20:44,385 --> 00:20:48,008
‫pour une ou plusieurs relations. Où l'on sait d'avance

426
00:20:48,008 --> 00:20:51,118
‫que le nombre de documents enfants n'augmentera pas autant.

427
00:20:51,118 --> 00:20:54,573
‫D'un autre côté, le référencement parent est mieux utilisé

428
00:20:54,573 --> 00:20:58,690
‫pour les relations un à plusieurs et un à une tonne

429
00:20:58,690 --> 00:21:00,927
‫comme celle-ci. D'accord?

430
00:21:00,927 --> 00:21:04,610
‫Encore une fois, gardez toujours à l'esprit que l'un des principes

431
00:21:04,610 --> 00:21:07,920
‫les plus importants de la modélisation de données MongoDB

432
00:21:07,920 --> 00:21:11,900
‫est que le tableau ne doit jamais être autorisé à croître indéfiniment.

433
00:21:11,900 --> 00:21:15,420
‫Afin de ne jamais dépasser cette limite de 16 mégaoctets.

434
00:21:15,420 --> 00:21:18,170
‫Nous ne voulons pas non plus envoyer à nos utilisateurs

435
00:21:18,170 --> 00:21:20,730
‫un tableau avec des milliers d'ID chaque fois qu'ils

436
00:21:20,730 --> 00:21:24,340
‫demandent un ensemble de données parent. D'accord?

437
00:21:24,340 --> 00:21:26,900
‫Alors, cette logique avait-elle un sens pour vous ?

438
00:21:26,900 --> 00:21:29,660
‫Passons ensuite au troisième type de référencement

439
00:21:29,660 --> 00:21:31,870
‫qui est le référencement bidirectionnel.

440
00:21:31,870 --> 00:21:34,395
‫Et cette fois, avec l'exemple du film et de l'acteur que

441
00:21:34,395 --> 00:21:36,380
‫je vous ai montré lorsque nous avons parlé

442
00:21:36,380 --> 00:21:39,364
‫de plusieurs à plusieurs relations. Vous vous en souvenez ?

443
00:21:39,364 --> 00:21:42,229
‫Encore une fois, chaque film a de nombreux acteurs

444
00:21:42,229 --> 00:21:44,880
‫et chaque acteur joue dans de nombreux films.

445
00:21:44,880 --> 00:21:48,464
‫Et c'est donc une relation typique de plusieurs à plusieurs.

446
00:21:48,464 --> 00:21:52,100
‫Et nous utilisons généralement ce référencement bidirectionnel pour concevoir des relations

447
00:21:52,100 --> 00:21:55,346
‫de plusieurs à plusieurs. Et ça marche comme

448
00:21:55,346 --> 00:21:59,370
‫ça ; dans chaque film, nous garderons des références à tous les

449
00:21:59,370 --> 00:22:03,980
‫acteurs qui jouent dans ce film. Donc un peu comme dans le référencement enfant.

450
00:22:03,980 --> 00:22:07,000
‫Cependant et en même temps dans chaque acteur, nous

451
00:22:07,000 --> 00:22:09,570
‫gardons également des références à tous les films

452
00:22:09,570 --> 00:22:11,660
‫dans lesquels l'acteur a joué.

453
00:22:11,660 --> 00:22:15,120
‫Ainsi, les films et les acteurs sont connectés dans les deux sens.

454
00:22:15,120 --> 00:22:17,900
‫Au nom donc référencement bidirectionnel.

455
00:22:17,900 --> 00:22:19,950
‫Et cela rend très facile

456
00:22:19,950 --> 00:22:23,290
‫la recherche de films et d'acteurs de manière totalement indépendante.

457
00:22:23,290 --> 00:22:25,910
‫Tout en facilitant également la recherche des

458
00:22:25,910 --> 00:22:29,029
‫acteurs associés à chaque film et les films associés

459
00:22:29,029 --> 00:22:30,383
‫à chaque acteur.

460
00:22:31,623 --> 00:22:32,560
‫(respiration profonde)

461
00:22:32,560 --> 00:22:34,747
‫C'était vraiment une longue conférence.

462
00:22:34,747 --> 00:22:38,030
‫Avec beaucoup de nouveaux concepts, principes et

463
00:22:38,030 --> 00:22:40,220
‫lignes directrices à retenir.

464
00:22:40,220 --> 00:22:43,460
‫Donc, afin de vous aider avec cela; voici un résumé

465
00:22:43,460 --> 00:22:46,650
‫rapide et quelques directives plus générales que vous pouvez consulter

466
00:22:46,650 --> 00:22:48,423
‫lorsque vous en avez besoin.

467
00:22:49,260 --> 00:22:52,753
‫Le principe le plus important est donc : structurez vos données pour

468
00:22:52,753 --> 00:22:56,120
‫qu'elles correspondent à la manière dont votre application interroge et met

469
00:22:56,120 --> 00:22:57,436
‫à jour les données.

470
00:22:57,436 --> 00:23:01,400
‫Ou en d'autres termes : identifiez d'abord les questions qui découlent des cas

471
00:23:01,400 --> 00:23:03,784
‫d'utilisation de votre application, puis modélisez vos

472
00:23:03,784 --> 00:23:06,634
‫données afin que les questions puissent obtenir une réponse

473
00:23:06,634 --> 00:23:08,995
‫de la manière la plus efficace.

474
00:23:08,995 --> 00:23:12,610
‫Par exemple; lorsque j'ai besoin d'interroger des films et des acteurs

475
00:23:12,610 --> 00:23:16,130
‫toujours ensemble ou existe-t-il des scénarios où je n'interroge que des

476
00:23:16,130 --> 00:23:18,041
‫films ou uniquement des acteurs.

477
00:23:18,041 --> 00:23:20,528
‫C'est sur ce genre de questions que

478
00:23:20,528 --> 00:23:22,930
‫votre modèle de données sera basé.

479
00:23:22,930 --> 00:23:26,730
‫En général, privilégiez toujours l'encastrement sauf s'il y a une bonne raison

480
00:23:26,730 --> 00:23:28,440
‫de ne pas l'encastrer.

481
00:23:28,440 --> 00:23:32,513
‫Surtout sur un à quelques-uns et un à plusieurs relations.

482
00:23:33,370 --> 00:23:37,713
‫Ensuite, une relation un à une tonne ou plusieurs à plusieurs est

483
00:23:37,713 --> 00:23:41,543
‫généralement une bonne raison de référencer au lieu d'intégrer.

484
00:23:41,543 --> 00:23:45,734
‫Privilégiez également le référencement lorsque les données sont beaucoup mises à

485
00:23:45,734 --> 00:23:50,717
‫jour et si vous avez besoin d'accéder fréquemment à un jeu de données seul.

486
00:23:50,717 --> 00:23:55,340
‫Utilisez l'intégration lorsque les données sont principalement lues mais rarement mises à jour et lorsque

487
00:23:55,340 --> 00:23:58,469
‫deux ensembles de données appartiennent intrinsèquement l'un à l'autre.

488
00:23:58,469 --> 00:24:02,840
‫Ne laissez pas les tableaux croître indéfiniment.

489
00:24:02,840 --> 00:24:05,982
‫Par conséquent, si vous souhaitez normaliser ; utilisez le référencement

490
00:24:05,982 --> 00:24:09,680
‫enfant pour les relations un à plusieurs et le référencement parent pour

491
00:24:09,680 --> 00:24:11,856
‫les relations un à une tonne.

492
00:24:11,856 --> 00:24:15,160
‫Et enfin, utilisez le référencement bidirectionnel pour

493
00:24:15,160 --> 00:24:17,520
‫plusieurs à plusieurs relations.

494
00:24:17,520 --> 00:24:18,720
‫D'accord?

495
00:24:18,720 --> 00:24:21,202
‫Et ça résume à peu près tout.

496
00:24:21,202 --> 00:24:23,970
‫En fait, je vous recommanderais de regarder cette vidéo

497
00:24:23,970 --> 00:24:27,144
‫deux fois si vous le pouvez, simplement à cause de

498
00:24:27,144 --> 00:24:30,091
‫l'importance de ce matériel. D'accord?

499
00:24:30,091 --> 00:24:33,363
‫Quoi qu'il en soit, à bientôt dans la prochaine vidéo.