‫Sprecher: Einer der wichtigsten
‫Schritte beim Erstellen datenintensiver Apps besteht darin, all diese
‫Daten tatsächlich in MongoDB zu modellieren.
‫Und darüber werden wir in diesem Vortrag sprechen.
‫Es ist also wirklich wichtig, dass Sie es
‫durchziehen, auch wenn es am Anfang viel zu beachten ist. Gut.
‫Wie auch immer, lass uns jetzt loslegen.
‫Nun ist die Datenmodellierung für Sie wahrscheinlich ein sehr neues Konzept.
‫Also bevor wir
‫anfangen; Lassen Sie uns klarstellen, worüber wir eigentlich sprechen werden.
‫Datenmodellierung ist also der Prozess, unstrukturierte Daten, die durch
‫ein reales Szenario generiert wurden, zu nehmen und
‫sie dann in einer Datenbank in ein logisches Datenmodell
‫zu strukturieren.
‫Und das tun wir nach einer Reihe
‫von Kriterien, die wir in diesem Video kennenlernen werden.
‫Zum Beispiel; Nehmen wir an, wir
‫wollen ein Online-Shop-Datenmodell entwerfen.
‫Es wird zunächst eine Menge unstrukturierter Daten geben, von denen wir wissen,
‫dass wir sie brauchen.
‫Rechts.
‫Sachen wie
‫Produkte, Kategorien, Kundenbestellungen, Warenkörbe, Lieferanten.
‫Und so weiter und so fort.
‫Unser Ziel bei der Datenmodellierung ist es, diese
‫Daten dann logisch zu strukturieren.
‫Spiegelt die realen Beziehungen wider,
‫die zwischen einigen dieser Datensätze bestehen.
‫Ein bisschen wie in diesem Beispiel zu sehen.
‫Und das ist natürlich nur eine Art imaginäre Situation, aber Sie
‫bekommen die Idee.
‫Rechts.
‫Heute sagen viele Backend-Entwickler, dass wir am meisten über
‫die Datenmodellierung nachdenken müssen.
‫Das ist der anspruchsvollste Teil beim Erstellen
‫einer gesamten Anwendung.
‫Denn es ist wirklich nicht immer geradlinig.
‫Und manchmal gibt es einfach keine richtigen Antworten.
‫Also nicht nur eine einzige korrekte Art, die Daten zu strukturieren.
‫Aber trotzdem werde ich mein Bestes tun, um den Prozess in
‫diesem Video darzustellen.
‫Und dafür gehen wir vier Schritte durch.
‫Also im ersten Schritt; Wir haben gelernt, wie man
‫verschiedene Arten von Beziehungen zwischen Daten identifiziert.
‫Dann
‫werden wir den Unterschied zwischen
‫Referenzierung oder Normalisierung und Einbettung oder Denormalisierung verstehen.
‫Im nächsten und
‫wichtigsten Schritt; Ich zeige Ihnen meinen Rahmen
‫für die Entscheidung, ob wir
‫Dokumente einbetten oder auf andere
‫Dokumente verweisen sollten, basierend auf verschiedenen Faktoren.
‫Außerdem müssen wir schnell über verschiedene
‫Arten der Referenzierung sprechen.
‫Denn das ist wichtig, wenn wir uns für diese Art
‫von Design für unsere Daten entscheiden.
‫Das wird also ein ziemlich theoretischer Vortrag.
‫Aber auch für Ihren Fortschritt als Backend-Entwickler
‫absolut unverzichtbar.
‫Denn die Art und Weise, wie wir Daten entwerfen, und die Art und Weise,
‫wie wir unsere Daten modellieren, kann unsere gesamte Anwendung ausmachen oder zerstören.
‫Und es wird viele Beispiele geben, die
‫diesen Prozess erleichtern.
‫Gut.
‫Und das erste, worüber wir
‫sprechen werden, sind die verschiedenen Arten
‫von Beziehungen, die zwischen Daten bestehen können.
‫Es gibt also drei große Arten von Beziehungen.
‫Eins zu eins, eins zu vielen und viele zu vielen.
‫Und ich werde in dieser
‫Folie eine Filmanwendung als Beispiel verwenden.
‫Okay?
‫Eine Eins-zu-Eins-Beziehung zwischen Daten besteht
‫also zunächst darin,
‫dass ein Feld nur einen Wert haben kann.
‫Also in unserem Filmanwendungsbeispiel; ein Film hat immer nur
‫einen Namen.
‫Dies ist also ein
‫einfaches Beispiel für eine Eins-zu-Eins-Beziehung.
‫Aber diese Beziehungen sind in Bezug auf die
‫Datenmodellierung nicht wirklich wichtig.
‫Jetzt sind die
‫wichtigsten Beziehungen die Eins-zu-Viele-Beziehungen.
‫Und sie sind so wichtig, dass
‫wir in MongoDB tatsächlich zwischen drei
‫Arten von Eins-zu-Viele-Beziehungen unterscheiden.
‫Eins zu wenigen, eins zu vielen und eins zu einer Tonne oder zu einer
‫Million oder so ähnlich. Der Unterschied hier basiert also
‫auf der relativen Menge der vielen. Gut.
‫Ein Beispiel für eine Eins-zu-eins-Beziehung ist
‫also, dass ein Film viele Preise gewinnen kann, aber eigentlich nur wenige.
‫Der Film wird also nicht tausend Preise gewinnen, aber er
‫kann einige gewinnen.
‫Dies ist also eine typische Eins-zu-wenige-Beziehung.
‫Sie sehen also, dass im Allgemeinen eine Eins-zu-Viele-Beziehung bedeutet,
‫dass ein Dokument mit vielen anderen Dokumenten in Beziehung stehen kann.
‫Ohne die JSON-Daten sieht dies jetzt vielleicht etwas abstrakt aus, aber genau
‫das ist hier der Zweck.
‫Ich möchte Ihnen nur einen konzeptionellen
‫Überblick über diese verschiedenen Arten von Beziehungen geben.
‫Wie auch immer, eine beliebige Eins-zu-Viele-Beziehung eines
‫Dokuments kann sich auf Hunderte oder Tausende anderer
‫Dokumente beziehen.
‫Zum Beispiel; Ein Film kann Tausende von Rezensionen
‫in unserer Anwendung haben.
‫Und so ist dies nicht wirklich eine Eins-zu-wenige, sondern eine
‫zu viele Beziehung. Okay?
‫Und schließlich haben wir die Eins-zu-Ton-Beziehung.
‫Stellen Sie sich vor, wir möchten einige Protokollierungsfunktionen in
‫unserer App implementieren. Im Grunde also, um genau zu
‫wissen, was auf unserem Server vor sich geht.
‫Diese Protokolle können dann leicht auf Millionen von Dokumenten anwachsen.
‫Dies ist also ein
‫sehr typisches Beispiel für eine Eins-zu-Tonnen-Beziehung.
‫Und der Unterschied zwischen vielen und einer Tonne
‫ist natürlich ein bisschen verschwommen, aber denke nur, wenn etwas
‫fast ins Unendliche wachsen kann, dann ist
‫es definitiv eine Eins-zu-Tonne-Beziehung.
‫Auch hier sind die eins zu vielen Beziehungen
‫die wichtigsten, die Sie kennen sollten.
‫Übrigens; in relationalen Datenbanken gibt
‫es nur eine zu vielen, ohne zu quantifizieren,
‫wie viel diese Anzahl tatsächlich ist.
‫In MongoDB-Datenbanken ist dies
‫jedoch ein äußerst wichtiger Unterschied.
‫Weil dies einer der Faktoren ist, die wir verwenden
‫werden, um zu entscheiden, ob wir
‫Daten denormalisieren oder normalisieren sollten, wie Sie später erfahren werden.
‫Wie auch immer, die weniger Art von Beziehung ist die Viele-zu-Viele,
‫bei der ein Film viele Schauspieler haben kann.
‫Aber gleichzeitig kann ein Schauspieler in vielen Filmen mitspielen.
‫Und so geht die Beziehung hier grundsätzlich
‫in beide Richtungen.
‫Wo zuvor bei den anderen Typen war
‫es nur in eine Richtung.
‫Zum Beispiel kann ein Film viele Rezensionen haben, aber eine
‫spezifische ist nur für diesen einen Film. Rechts.
‫Und das gleiche gilt für die Auszeichnungen.
‫Eine spezifische Auszeichnung wie für den besten Schauspieler
‫geht also nur an einen Film und nicht an mehrere.
‫Aber bei Filmen und Schauspielern ist das in der Tat anders.
‫Ein Film spielt also wieder viele Schauspieler, aber ein
‫Schauspieler spielt viele Filme und so
‫ist es eine viel zu viele Beziehung.
‫Okay.
‫Behalten Sie all dies im Hinterkopf, während wir jetzt in
‫diesem Vortrag vorankommen.
‫Und der wahrscheinlich wichtigste Aspekt, den wir
‫über MongoDB-Datenbanken lernen müssen, ist das Referenzieren
‫und Einbetten von zwei Datensätzen.
‫Und wir haben eigentlich schon ein
‫bisschen darüber gesprochen, aber lasst es uns hier noch einmal
‫Revue passieren lassen und auch etwas tiefer gehen.
‫Jedes Mal, wenn wir zwei zusammengehörige
‫Datensätze haben, können wir diese zusammengehörigen Daten entweder in
‫einer Referenz- oder normalisierten Form oder in einer eingebetteten oder denormalisierten Form darstellen.
‫Und ich verwende die beiden verwandten Begriffe weiterhin zusammen, wie
‫Referenzieren und Normalisieren, weil Sie sehen werden,
‫dass sie beide verwendet werden
‫und es daher wichtig ist, dass Sie alle kennen.
‫Wie auch immer, im referenzierten Formular halten wir zwei
‫zusammengehörige Datensätze und alle Dokumente getrennt.
‫Alle Daten sind also wieder schön getrennt, was
‫genau das bedeutet, was normalisiert bedeutet.
‫Um das Filmdatenbankbeispiel von vorhin fortzusetzen, hätten
‫wir ein Filmdokument und ein Schauspielerdokument
‫für jeden Schauspieler. Wie würden wir nun die
‫Verbindung zwischen Film und den Schauspielern herstellen, damit wir später in unserer
‫App zeigen können, welche Schauspieler in einem bestimmten Film gespielt haben.
‫Denn wenn sie alle völlig unterschiedliche Dokumente sind, hat der Film keine
‫Möglichkeit, etwas über die Schauspieler zu erfahren. Rechts.
‫Hier kommen die IDs ins Spiel.
‫Also verwenden wir die Schauspieler-IDs, um Verweise auf das
‫Filmdokument zu erstellen.
‫Filme effektiv mit Schauspielern verbinden.
‫Sie sehen also, dass wir in einem Filmdokument ein Array haben, in
‫dem wir die IDs aller Schauspieler gespeichert
‫haben, damit wir, wenn wir Daten zu einem bestimmten Film anfordern,
‫seine Schauspieler leicht identifizieren können. Ist das sinnvoll?
‫Nun wird diese Art der Referenzierung als untergeordnete Referenzierung bezeichnet, da es sich
‫in diesem Fall um den Film handelt, der
‫auf seine untergeordneten Elemente verweist. In diesem Fall die Schauspieler.
‫Wir schaffen hier also wirklich eine Art Hierarchie. Rechts.
‫Jetzt gibt es auch Elternreferenzen und wir
‫werden etwas später darüber sprechen.
‫Übrigens in relationalen Datenbanken; alle Daten werden auf diese
‫Weise immer in normalisierter Form dargestellt.
‫Aber in einer Datenbank ohne Fortsetzung wie
‫MongoDB können wir Daten in eine denormalisierte Form denormalisieren,
‫indem wir einfach das zugehörige
‫Dokument direkt in das Hauptdokument einbetten.
‫Jetzt haben wir alle relevanten
‫Daten über Schauspieler direkt in einem Hauptfilmdokument, ohne
‫dass separate Dokumente, Sammlungen und IDs erforderlich sind.
‫Wenn wir uns also entscheiden, unsere Daten zu denormalisieren oder einzubetten,
‫haben wir ein Hauptdokument, das alle Hauptdaten sowie die
‫zugehörigen Daten enthält. Gut.
‫Dies hat zur Folge, dass unsere Anwendung
‫weniger Abfragen an die Datenbank benötigt.
‫Denn wir können
‫alle Daten über Filme und Schauspieler
‫gleichzeitig abrufen, was natürlich unsere Leistung steigern wird.
‫Der Nachteil hier ist natürlich,
‫dass wir die eingebetteten Daten nicht wirklich alleine abfragen können.
‫Wenn dies also eine Anforderung für die Anwendung
‫ist, müssten Sie ein normalisiertes Design wählen
‫und da wir über Vor- und
‫Nachteile der denormalisierten Form sprechen; Machen wir
‫dasselbe mit dem normalisierten Design.
‫Und im Grunde ist es irgendwie das Gegenteil von
‫dem, worüber wir gerade gesprochen haben.
‫Es gibt also eine Leistungsverbesserung,
‫wenn wir oft die zugehörigen Daten alleine abfragen müssen, weil wir
‫dann nur die Daten abfragen können, die wir brauchen
‫und nicht immer Filme und Schauspieler zusammen.
‫Andererseits; Wenn wir tatsächlich Filme und Schauspieler
‫zusammen abfragen müssen, brauchen
‫wir viele Abfragen an die Datenbank.
‫Also zuerst die Abfrage für den Film und dann von dort
‫aus auch eine Abfrage für den Schauspieler und
‫das funktioniert natürlich für die Leistung.
‫Also beim Entwerfen Ihrer Datenbank; Dies ist die Art von Dingen, die Sie
‫im Auge behalten müssen. Gut.
‫Und jetzt nur als Randnotiz; Natürlich könnten wir unseren Denkprozess mit denormierten
‫Daten beginnen und dann zu dem
‫Schluss kommen, dass es am besten ist, die
‫Daten tatsächlich zu normalisieren.
‫Wenn man also über unser Datenmodell nachdenkt, funktioniert diese
‫Art der Datenorganisation natürlich in beide Richtungen.
‫Wie entscheiden wir nun eigentlich, ob wir die
‫Daten normalisieren oder denormalisieren sollen?
‫Genau das werden wir als nächstes lernen.
‫Wenn wir also zwei verwandte Datensätze haben; Wir müssen
‫uns entscheiden, ob wir die Datensätze einbetten oder ob
‫wir sie getrennt
‫halten und von einem Datensatz zum anderen verweisen.
‫Und ich habe diesen Entscheidungsrahmen entwickelt, den
‫ich Ihnen zeigen werde, bei dem wir drei Kriterien verwenden,
‫um diese Entscheidung zu treffen.
‫Zuerst betrachten wir die Art der
‫Beziehungen, die zwischen Datensätzen bestehen.
‫Zweitens versuchen wir, das Datenzugriffsmuster des
‫Datensatzes zu bestimmen, den wir entweder einbetten oder referenzieren möchten.
‫Und das bedeutet nur, zu analysieren, wie oft Daten in
‫diesem Datensatz gelesen und geschrieben werden.
‫Dann schauen wir uns auch etwas an, das ich Datennähe nenne.
‫Und Datennähe ist ein Begriff, den ich eigentlich gerade erfunden habe, aber
‫was es bedeutet, ist, wie viel die Daten wirklich miteinander verbunden sind und
‫wie wir die Daten aus der Datenbank abfragen wollen.
‫Und das wird mehr
‫Sinn ergeben, wenn wir gleich darüber sprechen.
‫Jetzt die Entscheidung treffen; Wir müssen alle diese
‫drei Kriterien kombinieren und
‫nicht nur eines davon isoliert verwenden.
‫Also zum Beispiel; Nur weil Kriterium Nummer eins sagt, dass wir
‫einbetten sollen, heißt das nicht, dass wir uns die anderen
‫beiden Kriterien nicht ansehen müssen.
‫Alles klar und fangen wir mit dem Beziehungstyp an.
‫Wenn wir also eine zu wenige Beziehung haben, betten wir normalerweise
‫den zugehörigen Datensatz in den Hauptdatensatz ein,
‫genau wie wir es auf der letzten
‫Folie gelernt haben. Rechts.
‫Jetzt in einer Eins-zu-Viele-Beziehung; Die Dinge sind etwas
‫unscharfer, daher ist es in Ordnung, entweder einzubetten oder zu verweisen.
‫In diesem Fall müssen wir nach
‫den anderen beiden Kriterien entscheiden.
‫Andererseits beziehen wir uns bei
‫einer Eins-zu-Tonne- oder einer Viele-zu-Viele-Beziehung normalerweise immer auf
‫die Daten. Das liegt daran, dass wir
‫bei einer Einbettung in diesem Fall schnell viel zu große Dokumente erstellen könnten.
‫Das Maximum von 16 Megabyte wird möglicherweise sogar überschritten.
‫Die Lösung dafür besteht natürlich darin, die Daten zu
‫referenzieren oder zu normalisieren. Und als kurzes
‫Beispiel; Nehmen wir an, in
‫unserem Filmdatenbankbeispiel sind jedem Film etwa 100 Bilder zugeordnet.
‫Wir könnten also sagen, es ist eine Eins-zu-Viele-Beziehung,
‫aber werden wir den Datensatz einbetten oder sollten wir
‫ihn hier eher referenzieren? Nun, wir wissen es nicht wirklich.
‫Werfen wir also einen Blick auf die anderen beiden Kriterien.
‫Beim zweiten geht es also um Datenzugriffsmuster, bei denen es sich
‫nur um eine ausgefallene
‫Beschreibung handelt, um zu bewerten, ob
‫ein bestimmter Datensatz hauptsächlich geschrieben oder hauptsächlich gelesen wird.
‫Wenn also der Datensatz, für den wir uns entscheiden, hauptsächlich gelesen
‫wird und die Daten nicht
‫oft aktualisiert werden, sollten wir diesen Datensatz wahrscheinlich einbetten.
‫Ein hohes Lese-/Schreibverhältnis bedeutet also nur, dass viel
‫mehr gelesen als geschrieben wird.
‫Und wieder ist ein Datensatz wie dieser ein guter Kandidat für
‫die Einbettung.
‫Der Grund dafür ist, dass wir durch die Einbettung nur eine
‫Fahrt in die Datenbank pro Abfrage benötigen.
‫Für die Referenzierung benötigen wir zwei Fahrten. Rechts.
‫Wenn wir also Daten einbetten, die viel gelesen werden;
‫Bei jeder Abfrage sparen wir einen
‫Weg zur Datenbank, was den gesamten Prozess wesentlich performanter macht.
‫Daher denke ich, dass unser Filmbild-Beispiel tatsächlich ein
‫guter Kandidat für die Einbettung wäre.
‫Denn sobald die 100 Bilder in der Datenbank gespeichert
‫sind, werden sie nicht mehr wirklich aktualisiert,
‫da es an einem Bild nicht wirklich etwas
‫zu aktualisieren gibt. Richtig, es geht
‫also nur ums Lesen und daher würden
‫wir anhand dieser Kriterien die abgebildeten Dokumente einbetten.
‫Wenn unsere Daten jedoch häufig aktualisiert werden, sollten
‫wir eine Referenzierung oder Normalisierung der Daten in Betracht ziehen.
‫Das liegt daran, dass die Datenbank-Engine mehr Arbeit benötigt,
‫um ein Dokument zu aktualisieren
‫und einzubetten, als ein einfacheres eigenständiges Dokument.
‫Und da unser Hauptziel Leistung ist; Wir
‫normalisieren nur den Datensatz.
‫Sagen wir in unserem Beispiel, dass jeder Film viele Rezensionen hat
‫und jede Rezension vom Benutzer als hilfreich markiert werden kann.
‫Jedes Mal, wenn jemand auf diese Bewertung klickt, war für unsere
‫Anwendung hilfreich. Wir müssen
‫das entsprechende Dokument aktualisieren.
‫Und das bedeutet, dass sich die Daten ständig ändern
‫können, und daher ist dies ein großartiger Kandidat für die Normalisierung.
‫Nochmals, weil wir nicht die ganze Zeit nach den
‫Filmen fragen wollen, ob wir wirklich nur die Rezensionen aktualisieren möchten, indem
‫wir sie als hilfreich markieren.
‫Okay, macht das Sinn?
‫Und schließlich die letzten Kriterien, die ich Datennähe nenne; das ist wie
‫ein Maß dafür, wie sehr die Daten miteinander
‫in Beziehung stehen. Wenn die
‫beiden Datensätze also wirklich untrennbar zusammengehören,
‫sollten sie wahrscheinlich ineinander eingebettet werden.
‫In unserem Beispiel; Alle Benutzer können viele E-Mail-Adressen in ihrem
‫Konto haben und da sie so untrennbar
‫mit dem Benutzer verbunden sind, sollten E-Mails zweifellos
‫in das Dokument eingebettet werden.
‫Wenn wir nun häufig beide Datensätze einzeln abfragen müssen, ist
‫dies ein sehr guter Grund,
‫die Daten in zwei separate Datensätze zu normalisieren.
‫Auch wenn sie eng verwandt sind.
‫Stellen Sie sich also vor, wir haben
‫in unserer App ein Quiz, bei dem Benutzer einen Film anhand von Bildern identifizieren müssen.
‫Das bedeutet, dass wir viele Bilder selbst
‫abfragen werden.
‫Also ohne unbedingt nach den Filmen selbst zu fragen.
‫Wenn wir dieses dritte Kriterium anwenden; kommen
‫wir zu dem Schluss, dass wir den Bilddatensatz eigentlich
‫normalisieren sollten. Gut.
‫Denn noch einmal, wenn wir diese Quiz-Funktionalität implementieren; Bilder
‫werden die ganze Zeit von selbst abgefragt.
‫All dies zeigt also, dass wir wirklich alle
‫drei Kriterien zusammen betrachten sollten
‫und nicht nur eines von ihnen isoliert.
‫Denn das könnte zu weniger optimalen Entscheidungen führen.
‫Und ich sage weniger optimal statt falsch,
‫weil sie nicht wirklich ganz richtig
‫oder ganz falsch sind, um unsere Daten zu modellieren.
‫Es gibt keine harten Regeln; Dies sind nur Richtlinien, die Sie befolgen
‫können, um die wahrscheinlich korrekteste Art
‫und Weise zu finden, Ihre Daten zu strukturieren.
‫Aber auch hier ist es schwer, wirklich falsch zu liegen.
‫Okay?
‫Nehmen wir nun an, wir haben uns entschieden, unsere
‫Datensätze zu normalisieren.
‫Also Referenzdaten.
‫Danach müssen wir uns
‫noch zwischen drei verschiedenen Referenzierungsarten entscheiden.
‫Untergeordnete Referenzierung, Elternreferenzierung und
‫bidirektionale Referenzierung.
‫Der erste Typ ist also die untergeordnete Referenzierung.
‫Welchen Referenzierungstyp habe ich Ihnen zuvor gezeigt.
‫Okay?
‫Und nehmen wir nicht das Fehlerprotokollierungsbeispiel, das ich
‫zuvor erwähnt habe. Wo wir
‫möglicherweise Millionen von gesperrten Dokumenten haben könnten.
‫Also beim Verweisen auf Kinder; Wir behalten grundsätzlich Verweise auf die
‫zugehörigen untergeordneten Dokumente in einem übergeordneten Dokument.
‫Und sie werden normalerweise in einem Array gespeichert.
‫Sie sehen also, dass jedes Protokoll eine ID
‫hat und dann im App-Dokument dieses Array mit all diesen
‫IDs ist. Rechts?
‫Das Problem hierbei ist jedoch, dass diese
‫Reihe von IDs sehr groß werden kann, wenn viele Kinder da sind.
‫Und dies ist ein Anti-Muster in MongoDB.
‫Also etwas, das wir um jeden Preis vermeiden sollten.
‫Außerdem sorgt die Kinderreferenzierung dafür,
‫dass Eltern und Kinder sehr eng miteinander verbunden sind.
‫Was nicht immer ideal ist. Aber genau
‫deshalb haben wir Elternreferenzen.
‫Also bei der Elternreferenzierung; es funktioniert
‫eigentlich andersherum.
‫Hier behalten wir also in jedem untergeordneten Dokument einen Verweis
‫auf das übergeordnete Element.
‫Daher der Name Elternreferenz.
‫In diesem Beispiel ist die App-ID 23 und daher
‫befindet sich in jedem Protokoll das
‫App-Feld mit der 23-ID darin.
‫Damit das Kind seine Eltern immer kennt.
‫In diesem Fall wissen die Eltern also eigentlich nichts
‫über die Kinder.
‫Nicht wer sie sind und nicht wie viele sie sind.
‫Sie sind also viel isolierter und eigenständiger.
‫Dabei kann es manchmal von Vorteil sein.
‫Welcher dieser beiden Typen ist also für diese
‫Datenbeziehung tatsächlich besser.
‫Und denken Sie daran, wie ich sagte, dass
‫es Millionen von Protokollen geben könnte und nehmen wir an, dass
‫es zwei Millionen protokollierte Dokumente gibt.
‫Im Fall einer untergeordneten Referenzierung würde dies bedeuten,
‫dass das App-Dokument
‫zwei Millionen ID-Referenzen enthält.
‫Rechts? Denken Sie jetzt auch daran, wie ich
‫gesagt habe, dass für Dokumente eine Beschränkung von 16 Megabyte gilt.
‫Wenn wir also diese untergeordneten IDs weiterhin zum Array auf dem
‫übergeordneten Element hinzufügen und hinzufügen; dann würden
‫wir ziemlich schnell die Grenze von 16 Megabyte erreichen,
‫die jedes Bson-Dokument aufnehmen kann.
‫Einfach, weil dieses Array so stark wachsen wird.
‫Das wird also nicht wirklich funktionieren.
‫Ist es?
‫Auf der anderen Seite wird dieses
‫Problem nicht auftreten, wenn die Eltern darauf verweisen.
‫Wir werden einfach wie zuvor zwei
‫Millionen gesperrte Dokumente haben, aber jedes von ihnen hat die ID seines Elternteils.
‫Aber es gibt kein Array,
‫das auf unbestimmte Zeit wächst, und daher
‫wäre eine Elternreferenzierung hier die beste Lösung.
‫Die Schlussfolgerung aus all dem ist, dass die Bezugnahme
‫auf Kinder im Allgemeinen am besten für eine
‫bis wenige Beziehungen verwendet wird. Wobei wir im Voraus wissen,
‫dass die Anzahl der untergeordneten Dokumente nicht so stark anwachsen wird.
‫Auf der anderen Seite wird die Elternreferenzierung
‫am besten für Eins-zu-Viele- und Eins-zu-Tonnen-Beziehungen wie diese
‫verwendet. Okay?
‫Denken Sie also immer daran, dass eines
‫der wichtigsten Prinzipien der MongoDB-Datenmodellierung
‫darin besteht, dass Arrays niemals unbegrenzt wachsen dürfen.
‫Um diese 16-Megabyte-Grenze nie zu überschreiten.
‫Wir möchten unseren Benutzern auch nicht jedes Mal ein
‫Array mit Tausenden von IDs senden, wenn sie
‫einen übergeordneten Datensatz anfordern. Okay?
‫War diese Logik für Sie sinnvoll?
‫Gehen wir dann zum dritten Referenzierungstyp über,
‫der eine bidirektionale Referenzierung ist.
‫Und dieses Mal mit dem Film- und Schauspielerbeispiel, das
‫ich Ihnen gezeigt habe, als wir über
‫viele zu viele Beziehungen sprachen. Erinnere dich daran?
‫Auch hier hat jeder Film viele Schauspieler und
‫jeder Schauspieler spielt in vielen Filmen.
‫Das ist also eine typische Viele-zu-Viele-Beziehung.
‫Und normalerweise verwenden wir diese bidirektionale Referenzierung, um viele zu
‫viele Beziehungen zu entwerfen. Und es funktioniert
‫so; In jedem Film werden wir Verweise auf alle Schauspieler
‫behalten, die in diesem Film mitspielen. Also ein bisschen wie bei der Referenzierung von Kindern.
‫Gleichzeitig halten wir in jedem Schauspieler jedoch auch
‫Verweise auf alle Filme, in denen
‫der Schauspieler mitgespielt hat.
‫Filme und Schauspieler sind also in beide Richtungen verbunden.
‫Daher der Name bidirektionale Referenzierung.
‫Und das macht es wirklich einfach,
‫sowohl nach Filmen als auch nach Schauspielern völlig unabhängig zu suchen.
‫Gleichzeitig ist es einfach, die jedem
‫Film zugeordneten Schauspieler und die jedem Schauspieler zugeordneten
‫Filme zu finden.
‫(tiefer Atemzug)
‫Das war wirklich ein ziemlich langer Vortrag.
‫Mit vielen neuen Konzepten und Prinzipien und Richtlinien,
‫die man sich merken sollte.
‫Um Ihnen dabei zu helfen; Hier ist eine kurze
‫Zusammenfassung und einige allgemeinere Richtlinien, die Sie sich
‫bei Bedarf ansehen können.
‫Das wichtigste Prinzip lautet also: Strukturieren Sie Ihre Daten so, dass
‫sie der Art und Weise entsprechen, wie Ihre Anwendung Daten
‫abfragt und aktualisiert.
‫Oder anders ausgedrückt: Identifizieren Sie zuerst die Fragen, die sich aus
‫den Anwendungsfällen Ihrer Anwendung ergeben, und
‫modellieren Sie dann Ihre Daten, damit die Fragen
‫möglichst effizient beantwortet werden können.
‫Zum Beispiel; wenn ich Filme und Schauspieler immer zusammen abfragen
‫muss oder es Szenarien gibt, in denen ich nur Filme
‫oder nur Schauspieler abfrage.
‫Auf solchen Fragen basiert
‫Ihr Datenmodell.
‫Im Allgemeinen sollten Sie das Einbetten immer bevorzugen, es sei denn, es gibt einen
‫guten Grund, es nicht einzubetten.
‫Vor allem bei einer zu wenigen und einer zu vielen Beziehungen.
‫Als nächstes ist eine Eins-zu-Tonnen- oder eine Viele-zu-Viele-Beziehung normalerweise ein guter
‫Grund, auf eine Referenz zu verweisen, anstatt sie einzubetten.
‫Bevorzugen Sie auch die Referenzierung, wenn Daten häufig
‫aktualisiert werden und Sie häufig allein auf einen Datensatz zugreifen müssen.
‫Verwenden Sie die Einbettung, wenn Daten hauptsächlich gelesen, aber selten aktualisiert
‫werden und wenn zwei Datensätze untrennbar zusammengehören.
‫Lassen Sie Arrays nicht unbegrenzt wachsen.
‫Wenn Sie daher normalisieren möchten; Verwenden
‫Sie die untergeordnete Referenzierung für 1-zu-viele-Beziehungen und
‫die Elternreferenzierung für 1-zu-viele-Beziehungen.
‫Und schließlich verwenden Sie die bidirektionale Referenzierung
‫für viele zu viele Beziehungen.
‫Gut?
‫Und das fasst es ziemlich gut zusammen.
‫Ich würde Ihnen sogar empfehlen, sich dieses
‫Video nach Möglichkeit zweimal anzusehen, nur weil dieses Material
‫wirklich wichtig ist. Gut?
‫Wie auch immer, wir sehen uns im nächsten Video.