‫Narrateur : L'une des étapes
‫les plus importantes dans la création d'applications gourmandes en données
‫consiste à modéliser toutes ces données dans MongoDB.
‫Et c'est ce dont nous allons parler dans cette conférence.
‫Il est donc vraiment crucial que vous
‫le suiviez, même au début, c'est beaucoup à assimiler. D'accord.
‫Quoi qu'il en soit, commençons maintenant.
‫Maintenant, la modélisation des données est probablement un concept très nouveau pour vous.
‫Alors avant de commencer
‫; permet de clarifier de quoi nous allons réellement parler.
‫Ainsi, la modélisation des données est le processus consistant à prendre des
‫données non structurées générées par un scénario du monde réel,
‫puis à les structurer en un modèle de données logique dans
‫une base de données.
‫Et nous le faisons selon un ensemble
‫de critères que nous allons découvrir dans cette vidéo.
‫Par exemple; disons que nous voulons concevoir un modèle
‫de données de boutique en ligne.
‫Il y aura initialement une tonne de données non structurées dont nous savons
‫que nous avons besoin.
‫Droit.
‫Des trucs comme des produits, des
‫catégories, des commandes de clients, des paniers d'achat, des fournisseurs.
‫Et ainsi de suite.
‫Notre objectif avec la modélisation des données est ensuite de
‫structurer ces données de manière logique.
‫Reflétant les relations réelles qui existent
‫entre certains de ces ensembles de données.
‫Un peu comme vous pouvez le voir dans cet exemple.
‫Et ce n'est bien sûr qu'une sorte de situation imaginaire mais
‫vous voyez l'idée.
‫Droit.
‫Maintenant, de nombreux développeurs backend disent que la modélisation des données est
‫l'endroit où nous devons le plus réfléchir.
‫C'est la partie la plus exigeante de la
‫création d'une application entière.
‫Parce que ce n'est vraiment pas toujours simple.
‫Et parfois, il n'y a tout simplement pas de bonnes réponses.
‫Il ne s'agit donc pas d'une seule manière correcte et unique de structurer les données.
‫Mais de toute façon, je ferai de mon mieux pour expliquer le
‫processus dans cette vidéo.
‫Et pour cela, nous allons passer par quatre étapes.
‫Donc dans la première étape; nous avons appris à identifier
‫différents types de relations entre les données.
‫Ensuite,
‫nous allons comprendre la différence entre
‫le référencement ou la normalisation et l'intégration ou la dénormalisation.
‫Dans l'étape suivante et
‫la plus importante ; Je vais vous montrer
‫mon cadre pour décider si nous
‫devons intégrer des documents ou faire référence
‫à d'autres documents en fonction de plusieurs facteurs différents.
‫Aussi, il faut parler rapidement des
‫différents types de référencement.
‫Parce que c'est important si c'est le type de conception
‫que nous choisissons pour nos données.
‫Ce sera donc en fait un cours assez théorique.
‫Mais aussi un élément absolument essentiel pour votre progression en
‫tant que développeur back-end.
‫Parce que la façon dont nous concevons les données et la façon dont
‫nous modélisons nos données peut faire ou défaire toute notre application.
‫Et il y aura beaucoup d'exemples en cours de route pour
‫rendre ce processus plus facile.
‫D'accord.
‫Et la première chose dont nous
‫allons parler, ce sont les différents types
‫de relations qui peuvent exister entre les données.
‫Il existe donc trois grands types de relations.
‫Un à un, un à plusieurs et plusieurs à plusieurs.
‫Et je vais utiliser une application
‫de film comme exemple dans cette diapositive.
‫D'accord?
‫Donc, d'abord, une relation un à un
‫entre les données est
‫fondamentalement lorsqu'un champ ne peut avoir qu'une seule valeur.
‫Donc, dans notre exemple d'application de film ; un film n'a
‫qu'un seul nom.
‫Et c'est donc un exemple
‫simple d'une relation un à un.
‫Mais ces relations ne sont pas vraiment importantes en
‫termes de modélisation des données.
‫Maintenant, les relations les
‫plus importantes sont celles d'un à plusieurs.
‫Et ils sont si importants que dans
‫MongoDB, nous distinguons en fait trois types de
‫relations un à plusieurs.
‫Un à quelques-uns, un à plusieurs, et un à une tonne ou à un million ou
‫quelque chose comme ça. Donc, la différence ici est
‫basée sur le montant relatif du nombre. D'accord.
‫Ainsi, un exemple de relation individuelle
‫est qu'un film peut remporter de nombreux prix, mais en réalité quelques-uns.
‫Donc le film ne va pas gagner mille récompenses mais
‫il peut en gagner.
‫Et c'est donc une relation typique d'un à quelques-uns.
‫Vous voyez donc qu'en général, une relation un à
‫plusieurs signifie qu'un document peut être lié à de nombreux autres documents.
‫Cela peut sembler un peu abstrait sans les données JSON, mais c'est
‫en fait le but ici.
‫Je veux juste vous montrer un
‫aperçu conceptuel de ces différents types de relations.
‫Quoi qu'il en soit, n'importe quelle relation un à
‫plusieurs, un document peut se rapporter à des centaines ou des
‫milliers d'autres documents.
‫Par exemple; un film peut avoir des milliers
‫de critiques dans notre application.
‫Et donc ce n'est pas vraiment une relation un à quelques
‫mais un à plusieurs. D'accord?
‫Et enfin, nous avons la relation un à tonne.
‫Imaginez que nous voulions implémenter une fonctionnalité de journalisation
‫dans notre application. Donc en gros pour savoir exactement
‫ce qui se passe sur notre serveur.
‫Ces journaux peuvent alors facilement atteindre des millions de documents.
‫Et c'est donc un exemple
‫très typique d'une relation entre deux personnes.
‫Et la différence entre plusieurs et une tonne est
‫bien sûr un peu floue, mais pensez simplement que si quelque chose
‫peut croître presque à l'infini, alors c'est certainement
‫une relation d'un à une tonne.
‫Encore une fois, les relations un à plusieurs
‫sont les plus importantes à connaître.
‫D'ailleurs; dans les bases de
‫données relationnelles, il n'y en a qu'un pour
‫plusieurs sans quantifier combien cela représente réellement.
‫Dans les bases de données
‫MongoDB, c'est une différence extrêmement importante.
‫Parce que c'est l'un des facteurs que nous allons utiliser
‫pour décider si nous devons dénormaliser ou
‫normaliser les données, comme vous l'apprendrez un peu plus tard.
‫Quoi qu'il en soit, le moins type de relation est le plusieurs
‫à plusieurs où un film peut avoir plusieurs acteurs.
‫Mais en même temps, un acteur peut jouer dans de nombreux films.
‫Et donc ici, la relation va essentiellement dans
‫les deux sens.
‫Là où auparavant dans les autres types,
‫ce n'était que dans un sens.
‫Par exemple, un film peut avoir plusieurs critiques, mais une
‫en particulier ne concerne que ce film. Droit.
‫Et il en va de même pour les récompenses.
‫Ainsi, un prix spécifique, comme celui du meilleur
‫acteur, est attribué à un seul film et non à plusieurs.
‫Mais avec les films et les acteurs, c'est effectivement différent.
‫Encore une fois, un film met en vedette de nombreux acteurs,
‫mais un acteur joue de nombreux
‫films et c'est donc une relation plusieurs à plusieurs.
‫D'accord.
‫Gardez donc tout cela à l'esprit alors que nous avançons maintenant
‫dans cette conférence.
‫Et probablement l'aspect le plus important que nous devons apprendre
‫sur les bases de données MongoDB est le référencement
‫et l'intégration de deux ensembles de données.
‫Et en fait, nous en
‫avons déjà parlé un peu auparavant, mais passons en
‫revue ici et approfondissons également un peu.
‫Ainsi, chaque fois que nous avons deux
‫ensembles de données liés, nous pouvons soit représenter ces données liées
‫sous une forme de référence ou normalisée, soit sous une forme intégrée ou dénormalisée.
‫Et je continue à utiliser les deux termes liés ensemble, comme
‫référencement et normalisation, car vous les verrez
‫tous les deux utilisés et
‫il est donc important que vous les connaissiez tous.
‫Quoi qu'il en soit, dans le formulaire référencé, nous gardons deux ensembles
‫de données liés et tous les documents séparés.
‫Encore une fois, toutes les données sont bien séparées, ce
‫qui est exactement ce que signifie la normalisation.
‫Donc, en continuant, l'exemple de base de données de films
‫d'avant nous aurions un document de film et un
‫document d'acteur pour chaque acteur. Maintenant, comment ferions-nous alors le lien
‫entre le film et les acteurs afin que plus tard dans notre application,
‫nous puissions montrer quels acteurs ont joué dans un film particulier.
‫Parce que s'ils sont tous complètement différents, le film n'a
‫aucun moyen de connaître les acteurs. Droit.
‫Eh bien, c'est là qu'interviennent les identifiants.
‫Nous utilisons donc les identifiants des acteurs afin de créer des références sur
‫le document du film.
‫Connecter efficacement les films avec les acteurs.
‫Ainsi, vous voyez que dans un document de film, nous avons un tableau
‫dans lequel nous stockons les identifiants de tous
‫les acteurs afin que lorsque nous demandons des données sur un certain film,
‫nous puissions facilement identifier ses acteurs. Cela a-t-il du sens?
‫Maintenant, ce type de référencement est appelé référencement enfant car c'est
‫le parent dans ce cas le film
‫qui référence ses enfants. Dans ce cas, les acteurs.
‫Donc, nous créons vraiment une sorte de hiérarchie ici. Droit.
‫Maintenant, il y a aussi le référencement parental et
‫nous en reparlerons un peu plus tard.
‫Et au passage dans les bases de données relationnelles ; toutes les données
‫sont toujours représentées sous une forme normalisée comme celle-ci.
‫Mais dans une base de données sans suite
‫comme MongoDB, nous pouvons dénormaliser les données sous une forme
‫dénormalisée simplement en incorporant le
‫document associé directement dans le document principal.
‫Alors maintenant, nous avons toutes les données
‫pertinentes sur les acteurs directement dans un document principal du film
‫sans avoir besoin de documents, de collections et d'identifiants séparés.
‫Encore une fois, si nous choisissons de dénormaliser ou d'intégrer nos données,
‫nous aurons un document principal contenant toutes les données principales ainsi que
‫les données associées. D'accord.
‫Et le résultat de ceci est que notre application aura besoin
‫de moins de requêtes dans la base de données.
‫Parce que nous pouvons
‫obtenir toutes les données sur les films et les
‫acteurs en même temps, ce qui augmentera bien sûr nos performances.
‫Maintenant, l'inconvénient ici est bien sûr
‫que nous ne pouvons pas vraiment interroger les données intégrées par elles-mêmes.
‫Et donc si c'est une exigence pour l'application, vous
‫devrez choisir une conception normalisée et puisque nous
‫parlons des avantages et des inconvénients
‫de la forme dénormalisée ; faisons de
‫même pour la conception normalisée.
‫Et fondamentalement, c'est un peu le contraire de
‫ce dont nous venons de parler.
‫Il y a donc une amélioration des
‫performances lorsque nous devons souvent interroger les données associées par nous-mêmes, car nous
‫pouvons alors simplement interroger les données dont nous avons besoin et
‫pas toujours les films et les acteurs ensemble.
‫Mais d'autre part; lorsque nous devons réellement interroger des films et
‫des acteurs ensemble, nous aurons alors besoin
‫de nombreuses requêtes dans la base de données.
‫Donc, d'abord la requête pour le film, puis à partir de là,
‫nous aurons également besoin d'une requête pour l'acteur et
‫cela fonctionne bien sûr pour la performance.
‫Ainsi, lors de la conception de votre base de données ; c'est le genre de choses que
‫vous devez garder à l'esprit. D'accord.
‫Et maintenant juste comme note latérale ; nous pourrions bien sûr commencer notre processus
‫de réflexion avec des données dénormalisées, puis
‫en arriver à la conclusion qu'il est préférable
‫de normaliser réellement les données.
‫Ainsi, lorsque l'on pense à notre modèle de données, cette façon
‫d'organiser les données fonctionne bien sûr dans les deux sens.
‫Maintenant, comment décidons-nous réellement si nous devons normaliser
‫ou dénormaliser les données ?
‫Eh bien, c'est exactement ce que nous allons apprendre ensuite.
‫Ainsi, lorsque nous avons deux ensembles de données liés ; nous devons
‫décider si nous allons intégrer les ensembles de données ou si
‫nous allons les garder séparés
‫et les référencer d'un ensemble de données à l'autre.
‫Et j'ai en quelque sorte développé ce cadre
‫de décision que je vais vous montrer où nous utilisons trois
‫critères pour prendre cette décision.
‫Tout d'abord, nous examinons le type de relations
‫qui existent entre les ensembles de données.
‫Deuxièmement, nous essayons de déterminer le modèle d'accès
‫aux données de l'ensemble de données que nous voulons intégrer ou référencer.
‫Et cela signifie simplement analyser la fréquence à laquelle les données sont lues
‫et écrites dans cet ensemble de données.
‫Ensuite, nous examinons également quelque chose que j'appelle la proximité des données.
‫Et la proximité des données est un terme que je viens d'inventer, mais
‫cela signifie à quel point les données sont vraiment liées et comment nous
‫voulons interroger les données de la base de données.
‫Et cela aura plus de
‫sens lorsque nous en parlerons dans un instant.
‫Maintenant, prendre réellement la décision ; nous devons combiner
‫tous ces trois critères
‫et ne pas utiliser l'un d'eux isolément.
‫Ainsi par exemple ; ce n'est pas parce que le critère
‫numéro un dit d'intégrer cela que nous n'avons pas besoin
‫d'examiner les deux autres critères.
‫Très bien et commençons par le type de relation.
‫Ainsi, généralement, lorsque nous avons une ou plusieurs relations, nous intégrons
‫toujours l'ensemble de données associé dans l'ensemble de
‫données principal, comme nous l'avons appris dans
‫la dernière diapositive. Droit.
‫Maintenant dans une relation un à plusieurs ; les choses
‫sont un peu plus floues, il est donc possible d'intégrer ou de référencer.
‫Dans ce cas, nous devrons décider
‫selon les deux autres critères.
‫D'un autre côté, sur une relation
‫un à une tonne ou plusieurs à plusieurs, nous référençons généralement
‫toujours les données. C'est parce que si nous
‫intégrions réellement dans ce cas, nous pourrions rapidement créer un document beaucoup trop volumineux.
‫Dépassant même potentiellement le maximum de 16 mégaoctets.
‫Et donc la solution pour cela est bien sûr de référencer
‫ou de normaliser les données. Et comme exemple rapide ;
‫disons que dans notre exemple de base
‫de données de films, nous avons environ 100 images associées à chaque film.
‫Nous pourrions donc dire que c'est une relation un
‫à plusieurs, mais allons-nous intégrer l'ensemble de données ou devrions-nous
‫plutôt les référencer ici. Eh bien, nous ne savons pas vraiment.
‫Jetons donc un œil aux deux autres critères.
‫Ainsi, le second concerne les modèles d'accès aux données où il
‫ne s'agit que d'une
‫description sophistiquée pour évaluer si un
‫certain ensemble de données est principalement écrit ou lu.
‫Donc, si l'ensemble de données sur lequel nous décidons est principalement lu et
‫que les données ne sont pas beaucoup
‫mises à jour, nous devrions probablement intégrer cet ensemble de données.
‫Ainsi, un rapport lecture/écriture élevé signifie simplement qu'il y
‫a beaucoup plus de lecture que d'écriture.
‫Et encore une fois, un ensemble de données comme celui-ci est un bon candidat
‫pour l'intégration.
‫La raison en est qu'en imbriquant, nous n'avons besoin que d'un seul
‫déplacement dans la base de données par requête.
‫Alors que pour le référencement nous avons besoin de deux voyages. Droit.
‫Donc, si nous intégrons des données qui sont beaucoup lues ;
‫à chaque requête, nous économisons un voyage vers
‫la base de données, ce qui rend l'ensemble du processus plus performant.
‫Je pense donc que notre exemple d'image de film
‫serait en fait un bon candidat pour l'intégration.
‫Car une fois que les 100 images sont enregistrées dans la base
‫de données, elles ne sont plus vraiment mises
‫à jour car il n'y a vraiment rien à mettre
‫à jour sur une image. D'accord, donc tout est
‫question de lecture et donc sur la
‫base de ce critère, nous intégrerions les documents imagés.
‫D'un autre côté, si nos données sont beaucoup mises
‫à jour, nous devrions envisager de référencer ou de normaliser les données.
‫C'est parce que c'est plus de travail pour le moteur de base
‫de données pour mettre à jour
‫et incorporer un document qu'un document autonome plus simple.
‫Et puisque notre objectif principal est la performance ;
‫nous normalisons simplement l'ensemble de données.
‫Dans notre exemple, disons que chaque film a de nombreuses critiques et
‫que chaque critique peut être marquée comme utile par l'utilisateur.
‫Ainsi, chaque fois que quelqu'un clique sur cet avis, cela a été utile
‫dans notre application. Nous devons
‫mettre à jour le document correspondant.
‫Et cela signifie que les données peuvent changer tout
‫le temps et c'est donc un excellent candidat pour la normalisation.
‫Encore une fois parce que nous ne voulons pas interroger les films
‫tout le temps si tout ce que nous voulons vraiment mettre à jour, ce sont
‫les critiques en les marquant comme utiles.
‫D'accord, est-ce que ça a du sens ?
‫Et enfin le dernier critère que j'appelle la proximité des données ;
‫qui est juste comme une mesure pour combien
‫les données sont liées. Donc, si les
‫deux ensembles de données appartiennent vraiment intrinsèquement, ils
‫devraient probablement être intégrés l'un dans l'autre.
‫Dans notre exemple ; tous les utilisateurs peuvent avoir plusieurs adresses e-mail
‫sur leur compte et puisqu'ils sont intrinsèquement connectés
‫à l'utilisateur, il ne fait aucun doute que les
‫e-mails doivent être intégrés au document.
‫Maintenant, si nous devons fréquemment interroger les deux ensembles de données,
‫c'est une très bonne raison de
‫normaliser les données en deux ensembles de données distincts.
‫Même s'ils sont étroitement liés.
‫Imaginez donc que dans notre application,
‫nous avons un quiz où les utilisateurs doivent identifier un film à partir d'images.
‫Cela signifie que nous allons interroger beaucoup d'images
‫par elles-mêmes.
‫Donc sans nécessairement interroger les films eux-mêmes.
‫Et donc si on applique ce troisième critère ;
‫nous arrivons à la conclusion que nous devrions réellement normaliser l'ensemble
‫de données d'image. D'accord.
‫Car encore une fois, si nous implémentons cette fonctionnalité de quiz ;
‫les images vont être interrogées d'elles-mêmes tout le temps.
‫Donc, tout cela montre que nous devrions vraiment
‫examiner les trois critères ensemble
‫plutôt que l'un d'entre eux isolément.
‫Parce que cela pourrait conduire à des décisions moins optimales.
‫Et je dis moins optimale au lieu de fausse
‫car ce ne sont pas vraiment des
‫manières totalement correctes ou totalement fausses de modéliser nos données.
‫Il n'y a pas de règles strictes ; ce sont juste des directives
‫que vous pouvez suivre pour trouver la
‫manière probablement la plus correcte de structurer vos données.
‫Mais encore une fois, il est difficile de se tromper vraiment.
‫D'accord?
‫Maintenant, disons que nous avons choisi de normaliser nos
‫jeux de données.
‫Donc en d'autres termes pour référencer des données.
‫Puis après il faut encore
‫choisir entre trois types de référencement différents.
‫Référencement enfant, référencement parent
‫et référencement bidirectionnel.
‫Le premier type est donc le référencement enfant.
‫Quel est le type de référencement que je vous ai déjà montré auparavant.
‫D'accord?
‫Et ne prenons pas l'exemple de journalisation des erreurs que
‫j'ai mentionné plus tôt. Où nous
‫pourrions potentiellement avoir des millions de documents verrouillés.
‫Donc, dans le référencement des enfants ; nous conservons essentiellement les références
‫aux documents enfants associés dans un document parent.
‫Et ils sont généralement stockés dans un tableau.
‫Vous voyez donc que chaque journal a un identifiant, puis
‫dans le document de l'application, il y a ce tableau avec
‫tous ces identifiants. Droit?
‫Cependant, le problème ici est que
‫ce tableau d'ID peut devenir très volumineux s'il y a beaucoup d'enfants.
‫Et c'est un anti-modèle dans MongoDB.
‫Donc quelque chose que nous devrions éviter à tout prix.
‫De plus, le référencement des enfants fait
‫en sorte que les parents et les enfants sont très étroitement liés.
‫Ce qui n'est pas toujours idéal. Mais c'est exactement pourquoi
‫nous avons le référencement des parents.
‫Donc dans le référencement parent ; cela fonctionne en
‫fait dans l'autre sens.
‫Donc ici, dans chaque document enfant, nous gardons une
‫référence à l'élément parent.
‫D'où le nom parent de référencement.
‫Dans cet exemple, l'ID d'application est 23 et donc
‫dans chaque journal, il y a le
‫champ d'application avec l'ID 23.
‫Pour que l'enfant connaisse toujours son parent.
‫Et donc dans ce cas, le parent ne sait
‫rien des enfants.
‫Ni qui ils sont ni combien ils sont.
‫Ainsi, ils sont beaucoup plus isolés et plus autonomes.
‫En cela, cela peut parfois être bénéfique.
‫Alors, lequel de ces deux types est le meilleur pour
‫cette relation de données.
‫Et rappelez-vous comment j'ai dit qu'il pourrait y
‫avoir des millions de journaux et supposons donc qu'il y ait
‫deux millions de documents enregistrés.
‫Dans un cas de référencement d'enfants, cela signifierait qu'il y
‫a deux millions de
‫références d'identification dans le document d'application.
‫Droit? Maintenant, rappelez-vous également comment j'ai dit qu'il
‫y a une limite de 16 mégaoctets sur les documents.
‫Donc, si nous continuions à ajouter et à ajouter ces ID enfants
‫dans le tableau sur le parent ; alors
‫nous atteindrions assez rapidement cette limite de 16 mégaoctets
‫que chaque document Bson peut contenir.
‫Tout simplement parce que ce tableau va tellement grandir.
‫Donc ça ne va pas vraiment marcher.
‫Est-ce?
‫D'un autre côté, avec le référencement
‫des parents, ce problème ne se produira pas.
‫Nous aurons simplement deux millions de
‫documents verrouillés comme avant, mais chacun d'eux détient l'ID de son parent.
‫Mais il n'y a pas de
‫tableau qui grandira indéfiniment et donc le
‫référencement parent serait la meilleure solution ici.
‫Donc, la conclusion de tout cela est qu'en
‫général, le référencement des enfants est mieux utilisé
‫pour une ou plusieurs relations. Où l'on sait d'avance
‫que le nombre de documents enfants n'augmentera pas autant.
‫D'un autre côté, le référencement parent est mieux utilisé
‫pour les relations un à plusieurs et un à une tonne
‫comme celle-ci. D'accord?
‫Encore une fois, gardez toujours à l'esprit que l'un des principes
‫les plus importants de la modélisation de données MongoDB
‫est que le tableau ne doit jamais être autorisé à croître indéfiniment.
‫Afin de ne jamais dépasser cette limite de 16 mégaoctets.
‫Nous ne voulons pas non plus envoyer à nos utilisateurs
‫un tableau avec des milliers d'ID chaque fois qu'ils
‫demandent un ensemble de données parent. D'accord?
‫Alors, cette logique avait-elle un sens pour vous ?
‫Passons ensuite au troisième type de référencement
‫qui est le référencement bidirectionnel.
‫Et cette fois, avec l'exemple du film et de l'acteur que
‫je vous ai montré lorsque nous avons parlé
‫de plusieurs à plusieurs relations. Vous vous en souvenez ?
‫Encore une fois, chaque film a de nombreux acteurs
‫et chaque acteur joue dans de nombreux films.
‫Et c'est donc une relation typique de plusieurs à plusieurs.
‫Et nous utilisons généralement ce référencement bidirectionnel pour concevoir des relations
‫de plusieurs à plusieurs. Et ça marche comme
‫ça ; dans chaque film, nous garderons des références à tous les
‫acteurs qui jouent dans ce film. Donc un peu comme dans le référencement enfant.
‫Cependant et en même temps dans chaque acteur, nous
‫gardons également des références à tous les films
‫dans lesquels l'acteur a joué.
‫Ainsi, les films et les acteurs sont connectés dans les deux sens.
‫Au nom donc référencement bidirectionnel.
‫Et cela rend très facile
‫la recherche de films et d'acteurs de manière totalement indépendante.
‫Tout en facilitant également la recherche des
‫acteurs associés à chaque film et les films associés
‫à chaque acteur.
‫(respiration profonde)
‫C'était vraiment une longue conférence.
‫Avec beaucoup de nouveaux concepts, principes et
‫lignes directrices à retenir.
‫Donc, afin de vous aider avec cela; voici un résumé
‫rapide et quelques directives plus générales que vous pouvez consulter
‫lorsque vous en avez besoin.
‫Le principe le plus important est donc : structurez vos données pour
‫qu'elles correspondent à la manière dont votre application interroge et met
‫à jour les données.
‫Ou en d'autres termes : identifiez d'abord les questions qui découlent des cas
‫d'utilisation de votre application, puis modélisez vos
‫données afin que les questions puissent obtenir une réponse
‫de la manière la plus efficace.
‫Par exemple; lorsque j'ai besoin d'interroger des films et des acteurs
‫toujours ensemble ou existe-t-il des scénarios où je n'interroge que des
‫films ou uniquement des acteurs.
‫C'est sur ce genre de questions que
‫votre modèle de données sera basé.
‫En général, privilégiez toujours l'encastrement sauf s'il y a une bonne raison
‫de ne pas l'encastrer.
‫Surtout sur un à quelques-uns et un à plusieurs relations.
‫Ensuite, une relation un à une tonne ou plusieurs à plusieurs est
‫généralement une bonne raison de référencer au lieu d'intégrer.
‫Privilégiez également le référencement lorsque les données sont beaucoup mises à
‫jour et si vous avez besoin d'accéder fréquemment à un jeu de données seul.
‫Utilisez l'intégration lorsque les données sont principalement lues mais rarement mises à jour et lorsque
‫deux ensembles de données appartiennent intrinsèquement l'un à l'autre.
‫Ne laissez pas les tableaux croître indéfiniment.
‫Par conséquent, si vous souhaitez normaliser ; utilisez le référencement
‫enfant pour les relations un à plusieurs et le référencement parent pour
‫les relations un à une tonne.
‫Et enfin, utilisez le référencement bidirectionnel pour
‫plusieurs à plusieurs relations.
‫D'accord?
‫Et ça résume à peu près tout.
‫En fait, je vous recommanderais de regarder cette vidéo
‫deux fois si vous le pouvez, simplement à cause de
‫l'importance de ce matériel. D'accord?
‫Quoi qu'il en soit, à bientôt dans la prochaine vidéo.