1 00:00:01,180 --> 00:00:02,990 ‫Sprecher: Einer der wichtigsten 2 00:00:02,990 --> 00:00:06,250 ‫Schritte beim Erstellen datenintensiver Apps besteht darin, all diese 3 00:00:06,250 --> 00:00:08,700 ‫Daten tatsächlich in MongoDB zu modellieren. 4 00:00:08,700 --> 00:00:12,300 ‫Und darüber werden wir in diesem Vortrag sprechen. 5 00:00:12,300 --> 00:00:14,710 ‫Es ist also wirklich wichtig, dass Sie es 6 00:00:14,710 --> 00:00:19,710 ‫durchziehen, auch wenn es am Anfang viel zu beachten ist. Gut. 7 00:00:19,810 --> 00:00:22,013 ‫Wie auch immer, lass uns jetzt loslegen. 8 00:00:23,530 --> 00:00:27,530 ‫Nun ist die Datenmodellierung für Sie wahrscheinlich ein sehr neues Konzept. 9 00:00:27,530 --> 00:00:28,920 ‫Also bevor wir 10 00:00:28,920 --> 00:00:32,070 ‫anfangen; Lassen Sie uns klarstellen, worüber wir eigentlich sprechen werden. 11 00:00:32,070 --> 00:00:35,656 ‫Datenmodellierung ist also der Prozess, unstrukturierte Daten, die durch 12 00:00:35,656 --> 00:00:38,770 ‫ein reales Szenario generiert wurden, zu nehmen und 13 00:00:38,770 --> 00:00:42,090 ‫sie dann in einer Datenbank in ein logisches Datenmodell 14 00:00:42,090 --> 00:00:43,410 ‫zu strukturieren. 15 00:00:43,410 --> 00:00:46,300 ‫Und das tun wir nach einer Reihe 16 00:00:46,300 --> 00:00:49,330 ‫von Kriterien, die wir in diesem Video kennenlernen werden. 17 00:00:49,330 --> 00:00:51,980 ‫Zum Beispiel; Nehmen wir an, wir 18 00:00:51,980 --> 00:00:54,120 ‫wollen ein Online-Shop-Datenmodell entwerfen. 19 00:00:54,120 --> 00:00:57,040 ‫Es wird zunächst eine Menge unstrukturierter Daten geben, von denen wir wissen, 20 00:00:57,040 --> 00:00:58,130 ‫dass wir sie brauchen. 21 00:00:58,130 --> 00:00:58,980 ‫Rechts. 22 00:00:58,980 --> 00:01:00,900 ‫Sachen wie 23 00:01:00,900 --> 00:01:03,875 ‫Produkte, Kategorien, Kundenbestellungen, Warenkörbe, Lieferanten. 24 00:01:03,875 --> 00:01:06,300 ‫Und so weiter und so fort. 25 00:01:06,300 --> 00:01:09,240 ‫Unser Ziel bei der Datenmodellierung ist es, diese 26 00:01:09,240 --> 00:01:11,450 ‫Daten dann logisch zu strukturieren. 27 00:01:11,450 --> 00:01:14,090 ‫Spiegelt die realen Beziehungen wider, 28 00:01:14,090 --> 00:01:16,920 ‫die zwischen einigen dieser Datensätze bestehen. 29 00:01:16,920 --> 00:01:19,670 ‫Ein bisschen wie in diesem Beispiel zu sehen. 30 00:01:19,670 --> 00:01:23,110 ‫Und das ist natürlich nur eine Art imaginäre Situation, aber Sie 31 00:01:23,110 --> 00:01:24,320 ‫bekommen die Idee. 32 00:01:24,320 --> 00:01:25,600 ‫Rechts. 33 00:01:25,600 --> 00:01:28,940 ‫Heute sagen viele Backend-Entwickler, dass wir am meisten über 34 00:01:28,940 --> 00:01:30,930 ‫die Datenmodellierung nachdenken müssen. 35 00:01:30,930 --> 00:01:33,670 ‫Das ist der anspruchsvollste Teil beim Erstellen 36 00:01:33,670 --> 00:01:35,310 ‫einer gesamten Anwendung. 37 00:01:35,310 --> 00:01:38,100 ‫Denn es ist wirklich nicht immer geradlinig. 38 00:01:38,100 --> 00:01:41,070 ‫Und manchmal gibt es einfach keine richtigen Antworten. 39 00:01:41,070 --> 00:01:45,500 ‫Also nicht nur eine einzige korrekte Art, die Daten zu strukturieren. 40 00:01:45,500 --> 00:01:48,420 ‫Aber trotzdem werde ich mein Bestes tun, um den Prozess in 41 00:01:48,420 --> 00:01:49,510 ‫diesem Video darzustellen. 42 00:01:49,510 --> 00:01:52,367 ‫Und dafür gehen wir vier Schritte durch. 43 00:01:52,367 --> 00:01:56,200 ‫Also im ersten Schritt; Wir haben gelernt, wie man 44 00:01:56,200 --> 00:01:59,340 ‫verschiedene Arten von Beziehungen zwischen Daten identifiziert. 45 00:01:59,340 --> 00:02:00,360 ‫Dann 46 00:02:00,360 --> 00:02:03,019 ‫werden wir den Unterschied zwischen 47 00:02:03,019 --> 00:02:07,163 ‫Referenzierung oder Normalisierung und Einbettung oder Denormalisierung verstehen. 48 00:02:07,163 --> 00:02:09,030 ‫Im nächsten und 49 00:02:09,030 --> 00:02:11,660 ‫wichtigsten Schritt; Ich zeige Ihnen meinen Rahmen 50 00:02:11,660 --> 00:02:13,560 ‫für die Entscheidung, ob wir 51 00:02:13,560 --> 00:02:15,750 ‫Dokumente einbetten oder auf andere 52 00:02:15,750 --> 00:02:18,690 ‫Dokumente verweisen sollten, basierend auf verschiedenen Faktoren. 53 00:02:18,690 --> 00:02:20,810 ‫Außerdem müssen wir schnell über verschiedene 54 00:02:20,810 --> 00:02:22,680 ‫Arten der Referenzierung sprechen. 55 00:02:22,680 --> 00:02:25,920 ‫Denn das ist wichtig, wenn wir uns für diese Art 56 00:02:25,920 --> 00:02:28,220 ‫von Design für unsere Daten entscheiden. 57 00:02:28,220 --> 00:02:32,290 ‫Das wird also ein ziemlich theoretischer Vortrag. 58 00:02:32,290 --> 00:02:35,940 ‫Aber auch für Ihren Fortschritt als Backend-Entwickler 59 00:02:35,940 --> 00:02:37,660 ‫absolut unverzichtbar. 60 00:02:37,660 --> 00:02:41,553 ‫Denn die Art und Weise, wie wir Daten entwerfen, und die Art und Weise, 61 00:02:41,553 --> 00:02:45,180 ‫wie wir unsere Daten modellieren, kann unsere gesamte Anwendung ausmachen oder zerstören. 62 00:02:45,180 --> 00:02:47,950 ‫Und es wird viele Beispiele geben, die 63 00:02:47,950 --> 00:02:49,510 ‫diesen Prozess erleichtern. 64 00:02:49,510 --> 00:02:50,343 ‫Gut. 65 00:02:51,320 --> 00:02:53,440 ‫Und das erste, worüber wir 66 00:02:53,440 --> 00:02:55,780 ‫sprechen werden, sind die verschiedenen Arten 67 00:02:55,780 --> 00:02:58,210 ‫von Beziehungen, die zwischen Daten bestehen können. 68 00:02:58,210 --> 00:03:00,780 ‫Es gibt also drei große Arten von Beziehungen. 69 00:03:00,780 --> 00:03:05,150 ‫Eins zu eins, eins zu vielen und viele zu vielen. 70 00:03:05,150 --> 00:03:06,990 ‫Und ich werde in dieser 71 00:03:06,990 --> 00:03:08,890 ‫Folie eine Filmanwendung als Beispiel verwenden. 72 00:03:08,890 --> 00:03:10,000 ‫Okay? 73 00:03:10,000 --> 00:03:12,440 ‫Eine Eins-zu-Eins-Beziehung zwischen Daten besteht 74 00:03:12,440 --> 00:03:14,140 ‫also zunächst darin, 75 00:03:14,140 --> 00:03:17,370 ‫dass ein Feld nur einen Wert haben kann. 76 00:03:17,370 --> 00:03:21,550 ‫Also in unserem Filmanwendungsbeispiel; ein Film hat immer nur 77 00:03:21,550 --> 00:03:22,990 ‫einen Namen. 78 00:03:22,990 --> 00:03:24,910 ‫Dies ist also ein 79 00:03:24,910 --> 00:03:27,160 ‫einfaches Beispiel für eine Eins-zu-Eins-Beziehung. 80 00:03:27,160 --> 00:03:29,690 ‫Aber diese Beziehungen sind in Bezug auf die 81 00:03:29,690 --> 00:03:31,363 ‫Datenmodellierung nicht wirklich wichtig. 82 00:03:32,330 --> 00:03:34,430 ‫Jetzt sind die 83 00:03:34,430 --> 00:03:37,210 ‫wichtigsten Beziehungen die Eins-zu-Viele-Beziehungen. 84 00:03:37,210 --> 00:03:39,770 ‫Und sie sind so wichtig, dass 85 00:03:39,770 --> 00:03:42,510 ‫wir in MongoDB tatsächlich zwischen drei 86 00:03:42,510 --> 00:03:44,540 ‫Arten von Eins-zu-Viele-Beziehungen unterscheiden. 87 00:03:44,540 --> 00:03:49,540 ‫Eins zu wenigen, eins zu vielen und eins zu einer Tonne oder zu einer 88 00:03:49,910 --> 00:03:53,230 ‫Million oder so ähnlich. Der Unterschied hier basiert also 89 00:03:53,230 --> 00:03:56,893 ‫auf der relativen Menge der vielen. Gut. 90 00:03:57,840 --> 00:04:00,969 ‫Ein Beispiel für eine Eins-zu-eins-Beziehung ist 91 00:04:00,969 --> 00:04:05,967 ‫also, dass ein Film viele Preise gewinnen kann, aber eigentlich nur wenige. 92 00:04:05,967 --> 00:04:09,630 ‫Der Film wird also nicht tausend Preise gewinnen, aber er 93 00:04:09,630 --> 00:04:11,220 ‫kann einige gewinnen. 94 00:04:11,220 --> 00:04:14,930 ‫Dies ist also eine typische Eins-zu-wenige-Beziehung. 95 00:04:14,930 --> 00:04:18,710 ‫Sie sehen also, dass im Allgemeinen eine Eins-zu-Viele-Beziehung bedeutet, 96 00:04:18,710 --> 00:04:23,210 ‫dass ein Dokument mit vielen anderen Dokumenten in Beziehung stehen kann. 97 00:04:23,210 --> 00:04:26,680 ‫Ohne die JSON-Daten sieht dies jetzt vielleicht etwas abstrakt aus, aber genau 98 00:04:26,680 --> 00:04:28,480 ‫das ist hier der Zweck. 99 00:04:28,480 --> 00:04:31,040 ‫Ich möchte Ihnen nur einen konzeptionellen 100 00:04:31,040 --> 00:04:33,759 ‫Überblick über diese verschiedenen Arten von Beziehungen geben. 101 00:04:33,759 --> 00:04:36,872 ‫Wie auch immer, eine beliebige Eins-zu-Viele-Beziehung eines 102 00:04:36,872 --> 00:04:40,600 ‫Dokuments kann sich auf Hunderte oder Tausende anderer 103 00:04:40,600 --> 00:04:42,070 ‫Dokumente beziehen. 104 00:04:42,070 --> 00:04:44,788 ‫Zum Beispiel; Ein Film kann Tausende von Rezensionen 105 00:04:44,788 --> 00:04:46,710 ‫in unserer Anwendung haben. 106 00:04:46,710 --> 00:04:49,380 ‫Und so ist dies nicht wirklich eine Eins-zu-wenige, sondern eine 107 00:04:49,380 --> 00:04:51,524 ‫zu viele Beziehung. Okay? 108 00:04:51,524 --> 00:04:55,616 ‫Und schließlich haben wir die Eins-zu-Ton-Beziehung. 109 00:04:55,616 --> 00:04:59,720 ‫Stellen Sie sich vor, wir möchten einige Protokollierungsfunktionen in 110 00:04:59,720 --> 00:05:03,110 ‫unserer App implementieren. Im Grunde also, um genau zu 111 00:05:03,110 --> 00:05:04,870 ‫wissen, was auf unserem Server vor sich geht. 112 00:05:04,870 --> 00:05:08,770 ‫Diese Protokolle können dann leicht auf Millionen von Dokumenten anwachsen. 113 00:05:08,770 --> 00:05:11,270 ‫Dies ist also ein 114 00:05:11,270 --> 00:05:14,200 ‫sehr typisches Beispiel für eine Eins-zu-Tonnen-Beziehung. 115 00:05:14,200 --> 00:05:17,100 ‫Und der Unterschied zwischen vielen und einer Tonne 116 00:05:17,100 --> 00:05:20,730 ‫ist natürlich ein bisschen verschwommen, aber denke nur, wenn etwas 117 00:05:20,730 --> 00:05:23,360 ‫fast ins Unendliche wachsen kann, dann ist 118 00:05:23,360 --> 00:05:25,532 ‫es definitiv eine Eins-zu-Tonne-Beziehung. 119 00:05:25,532 --> 00:05:28,763 ‫Auch hier sind die eins zu vielen Beziehungen 120 00:05:28,763 --> 00:05:31,650 ‫die wichtigsten, die Sie kennen sollten. 121 00:05:31,650 --> 00:05:34,050 ‫Übrigens; in relationalen Datenbanken gibt 122 00:05:34,050 --> 00:05:37,061 ‫es nur eine zu vielen, ohne zu quantifizieren, 123 00:05:37,061 --> 00:05:39,800 ‫wie viel diese Anzahl tatsächlich ist. 124 00:05:39,800 --> 00:05:41,800 ‫In MongoDB-Datenbanken ist dies 125 00:05:41,800 --> 00:05:44,010 ‫jedoch ein äußerst wichtiger Unterschied. 126 00:05:44,010 --> 00:05:47,150 ‫Weil dies einer der Faktoren ist, die wir verwenden 127 00:05:47,150 --> 00:05:49,891 ‫werden, um zu entscheiden, ob wir 128 00:05:49,891 --> 00:05:53,340 ‫Daten denormalisieren oder normalisieren sollten, wie Sie später erfahren werden. 129 00:05:53,340 --> 00:05:57,181 ‫Wie auch immer, die weniger Art von Beziehung ist die Viele-zu-Viele, 130 00:05:57,181 --> 00:06:00,149 ‫bei der ein Film viele Schauspieler haben kann. 131 00:06:00,149 --> 00:06:04,876 ‫Aber gleichzeitig kann ein Schauspieler in vielen Filmen mitspielen. 132 00:06:04,876 --> 00:06:07,910 ‫Und so geht die Beziehung hier grundsätzlich 133 00:06:07,910 --> 00:06:09,630 ‫in beide Richtungen. 134 00:06:09,630 --> 00:06:11,800 ‫Wo zuvor bei den anderen Typen war 135 00:06:11,800 --> 00:06:13,939 ‫es nur in eine Richtung. 136 00:06:13,939 --> 00:06:17,470 ‫Zum Beispiel kann ein Film viele Rezensionen haben, aber eine 137 00:06:17,470 --> 00:06:22,450 ‫spezifische ist nur für diesen einen Film. Rechts. 138 00:06:22,450 --> 00:06:24,560 ‫Und das gleiche gilt für die Auszeichnungen. 139 00:06:24,560 --> 00:06:27,506 ‫Eine spezifische Auszeichnung wie für den besten Schauspieler 140 00:06:27,506 --> 00:06:30,914 ‫geht also nur an einen Film und nicht an mehrere. 141 00:06:30,914 --> 00:06:35,580 ‫Aber bei Filmen und Schauspielern ist das in der Tat anders. 142 00:06:35,580 --> 00:06:39,250 ‫Ein Film spielt also wieder viele Schauspieler, aber ein 143 00:06:39,250 --> 00:06:41,920 ‫Schauspieler spielt viele Filme und so 144 00:06:41,920 --> 00:06:45,020 ‫ist es eine viel zu viele Beziehung. 145 00:06:45,020 --> 00:06:46,170 ‫Okay. 146 00:06:46,170 --> 00:06:49,060 ‫Behalten Sie all dies im Hinterkopf, während wir jetzt in 147 00:06:49,060 --> 00:06:50,063 ‫diesem Vortrag vorankommen. 148 00:06:51,760 --> 00:06:54,870 ‫Und der wahrscheinlich wichtigste Aspekt, den wir 149 00:06:54,870 --> 00:06:57,900 ‫über MongoDB-Datenbanken lernen müssen, ist das Referenzieren 150 00:06:57,900 --> 00:07:00,340 ‫und Einbetten von zwei Datensätzen. 151 00:07:00,340 --> 00:07:02,350 ‫Und wir haben eigentlich schon ein 152 00:07:02,350 --> 00:07:05,050 ‫bisschen darüber gesprochen, aber lasst es uns hier noch einmal 153 00:07:05,050 --> 00:07:07,311 ‫Revue passieren lassen und auch etwas tiefer gehen. 154 00:07:07,311 --> 00:07:09,962 ‫Jedes Mal, wenn wir zwei zusammengehörige 155 00:07:09,962 --> 00:07:13,829 ‫Datensätze haben, können wir diese zusammengehörigen Daten entweder in 156 00:07:13,829 --> 00:07:18,829 ‫einer Referenz- oder normalisierten Form oder in einer eingebetteten oder denormalisierten Form darstellen. 157 00:07:18,842 --> 00:07:22,190 ‫Und ich verwende die beiden verwandten Begriffe weiterhin zusammen, wie 158 00:07:22,190 --> 00:07:24,340 ‫Referenzieren und Normalisieren, weil Sie sehen werden, 159 00:07:24,340 --> 00:07:26,460 ‫dass sie beide verwendet werden 160 00:07:26,460 --> 00:07:29,510 ‫und es daher wichtig ist, dass Sie alle kennen. 161 00:07:29,510 --> 00:07:33,070 ‫Wie auch immer, im referenzierten Formular halten wir zwei 162 00:07:33,070 --> 00:07:35,826 ‫zusammengehörige Datensätze und alle Dokumente getrennt. 163 00:07:35,826 --> 00:07:39,589 ‫Alle Daten sind also wieder schön getrennt, was 164 00:07:39,589 --> 00:07:43,275 ‫genau das bedeutet, was normalisiert bedeutet. 165 00:07:43,275 --> 00:07:47,110 ‫Um das Filmdatenbankbeispiel von vorhin fortzusetzen, hätten 166 00:07:47,110 --> 00:07:50,750 ‫wir ein Filmdokument und ein Schauspielerdokument 167 00:07:50,750 --> 00:07:54,870 ‫für jeden Schauspieler. Wie würden wir nun die 168 00:07:54,870 --> 00:07:58,710 ‫Verbindung zwischen Film und den Schauspielern herstellen, damit wir später in unserer 169 00:07:58,710 --> 00:08:02,150 ‫App zeigen können, welche Schauspieler in einem bestimmten Film gespielt haben. 170 00:08:02,150 --> 00:08:05,210 ‫Denn wenn sie alle völlig unterschiedliche Dokumente sind, hat der Film keine 171 00:08:05,210 --> 00:08:09,438 ‫Möglichkeit, etwas über die Schauspieler zu erfahren. Rechts. 172 00:08:09,438 --> 00:08:12,253 ‫Hier kommen die IDs ins Spiel. 173 00:08:12,253 --> 00:08:16,460 ‫Also verwenden wir die Schauspieler-IDs, um Verweise auf das 174 00:08:16,460 --> 00:08:18,020 ‫Filmdokument zu erstellen. 175 00:08:18,020 --> 00:08:20,981 ‫Filme effektiv mit Schauspielern verbinden. 176 00:08:20,981 --> 00:08:24,760 ‫Sie sehen also, dass wir in einem Filmdokument ein Array haben, in 177 00:08:24,760 --> 00:08:27,198 ‫dem wir die IDs aller Schauspieler gespeichert 178 00:08:27,198 --> 00:08:30,760 ‫haben, damit wir, wenn wir Daten zu einem bestimmten Film anfordern, 179 00:08:30,760 --> 00:08:34,553 ‫seine Schauspieler leicht identifizieren können. Ist das sinnvoll? 180 00:08:34,553 --> 00:08:38,830 ‫Nun wird diese Art der Referenzierung als untergeordnete Referenzierung bezeichnet, da es sich 181 00:08:38,830 --> 00:08:41,480 ‫in diesem Fall um den Film handelt, der 182 00:08:41,480 --> 00:08:45,104 ‫auf seine untergeordneten Elemente verweist. In diesem Fall die Schauspieler. 183 00:08:45,104 --> 00:08:48,841 ‫Wir schaffen hier also wirklich eine Art Hierarchie. Rechts. 184 00:08:48,841 --> 00:08:51,870 ‫Jetzt gibt es auch Elternreferenzen und wir 185 00:08:51,870 --> 00:08:54,390 ‫werden etwas später darüber sprechen. 186 00:08:54,390 --> 00:08:58,710 ‫Übrigens in relationalen Datenbanken; alle Daten werden auf diese 187 00:08:58,710 --> 00:09:01,958 ‫Weise immer in normalisierter Form dargestellt. 188 00:09:01,958 --> 00:09:05,490 ‫Aber in einer Datenbank ohne Fortsetzung wie 189 00:09:05,490 --> 00:09:09,700 ‫MongoDB können wir Daten in eine denormalisierte Form denormalisieren, 190 00:09:09,700 --> 00:09:12,450 ‫indem wir einfach das zugehörige 191 00:09:12,450 --> 00:09:15,330 ‫Dokument direkt in das Hauptdokument einbetten. 192 00:09:15,330 --> 00:09:18,330 ‫Jetzt haben wir alle relevanten 193 00:09:18,330 --> 00:09:22,060 ‫Daten über Schauspieler direkt in einem Hauptfilmdokument, ohne 194 00:09:22,060 --> 00:09:25,700 ‫dass separate Dokumente, Sammlungen und IDs erforderlich sind. 195 00:09:25,700 --> 00:09:30,088 ‫Wenn wir uns also entscheiden, unsere Daten zu denormalisieren oder einzubetten, 196 00:09:30,088 --> 00:09:34,280 ‫haben wir ein Hauptdokument, das alle Hauptdaten sowie die 197 00:09:34,280 --> 00:09:37,197 ‫zugehörigen Daten enthält. Gut. 198 00:09:37,197 --> 00:09:40,340 ‫Dies hat zur Folge, dass unsere Anwendung 199 00:09:40,340 --> 00:09:43,330 ‫weniger Abfragen an die Datenbank benötigt. 200 00:09:43,330 --> 00:09:45,000 ‫Denn wir können 201 00:09:45,000 --> 00:09:48,074 ‫alle Daten über Filme und Schauspieler 202 00:09:48,074 --> 00:09:51,650 ‫gleichzeitig abrufen, was natürlich unsere Leistung steigern wird. 203 00:09:51,650 --> 00:09:53,840 ‫Der Nachteil hier ist natürlich, 204 00:09:53,840 --> 00:09:57,530 ‫dass wir die eingebetteten Daten nicht wirklich alleine abfragen können. 205 00:09:57,530 --> 00:10:00,810 ‫Wenn dies also eine Anforderung für die Anwendung 206 00:10:00,810 --> 00:10:03,790 ‫ist, müssten Sie ein normalisiertes Design wählen 207 00:10:03,790 --> 00:10:06,280 ‫und da wir über Vor- und 208 00:10:06,280 --> 00:10:09,030 ‫Nachteile der denormalisierten Form sprechen; Machen wir 209 00:10:09,030 --> 00:10:11,490 ‫dasselbe mit dem normalisierten Design. 210 00:10:11,490 --> 00:10:13,920 ‫Und im Grunde ist es irgendwie das Gegenteil von 211 00:10:13,920 --> 00:10:15,770 ‫dem, worüber wir gerade gesprochen haben. 212 00:10:15,770 --> 00:10:18,319 ‫Es gibt also eine Leistungsverbesserung, 213 00:10:18,319 --> 00:10:22,390 ‫wenn wir oft die zugehörigen Daten alleine abfragen müssen, weil wir 214 00:10:22,390 --> 00:10:25,740 ‫dann nur die Daten abfragen können, die wir brauchen 215 00:10:25,740 --> 00:10:28,490 ‫und nicht immer Filme und Schauspieler zusammen. 216 00:10:28,490 --> 00:10:31,640 ‫Andererseits; Wenn wir tatsächlich Filme und Schauspieler 217 00:10:31,640 --> 00:10:33,906 ‫zusammen abfragen müssen, brauchen 218 00:10:33,906 --> 00:10:36,396 ‫wir viele Abfragen an die Datenbank. 219 00:10:36,396 --> 00:10:40,010 ‫Also zuerst die Abfrage für den Film und dann von dort 220 00:10:40,010 --> 00:10:42,610 ‫aus auch eine Abfrage für den Schauspieler und 221 00:10:42,610 --> 00:10:44,989 ‫das funktioniert natürlich für die Leistung. 222 00:10:44,989 --> 00:10:48,328 ‫Also beim Entwerfen Ihrer Datenbank; Dies ist die Art von Dingen, die Sie 223 00:10:48,328 --> 00:10:50,569 ‫im Auge behalten müssen. Gut. 224 00:10:50,569 --> 00:10:54,900 ‫Und jetzt nur als Randnotiz; Natürlich könnten wir unseren Denkprozess mit denormierten 225 00:10:54,900 --> 00:10:56,994 ‫Daten beginnen und dann zu dem 226 00:10:56,994 --> 00:10:59,670 ‫Schluss kommen, dass es am besten ist, die 227 00:10:59,670 --> 00:11:01,692 ‫Daten tatsächlich zu normalisieren. 228 00:11:01,692 --> 00:11:05,043 ‫Wenn man also über unser Datenmodell nachdenkt, funktioniert diese 229 00:11:05,043 --> 00:11:08,378 ‫Art der Datenorganisation natürlich in beide Richtungen. 230 00:11:08,378 --> 00:11:12,570 ‫Wie entscheiden wir nun eigentlich, ob wir die 231 00:11:12,570 --> 00:11:15,330 ‫Daten normalisieren oder denormalisieren sollen? 232 00:11:15,330 --> 00:11:18,033 ‫Genau das werden wir als nächstes lernen. 233 00:11:19,690 --> 00:11:22,974 ‫Wenn wir also zwei verwandte Datensätze haben; Wir müssen 234 00:11:22,974 --> 00:11:26,180 ‫uns entscheiden, ob wir die Datensätze einbetten oder ob 235 00:11:26,180 --> 00:11:27,693 ‫wir sie getrennt 236 00:11:27,693 --> 00:11:30,400 ‫halten und von einem Datensatz zum anderen verweisen. 237 00:11:30,400 --> 00:11:32,730 ‫Und ich habe diesen Entscheidungsrahmen entwickelt, den 238 00:11:32,730 --> 00:11:36,070 ‫ich Ihnen zeigen werde, bei dem wir drei Kriterien verwenden, 239 00:11:36,070 --> 00:11:37,770 ‫um diese Entscheidung zu treffen. 240 00:11:37,770 --> 00:11:40,450 ‫Zuerst betrachten wir die Art der 241 00:11:40,450 --> 00:11:42,800 ‫Beziehungen, die zwischen Datensätzen bestehen. 242 00:11:42,800 --> 00:11:45,856 ‫Zweitens versuchen wir, das Datenzugriffsmuster des 243 00:11:45,856 --> 00:11:50,150 ‫Datensatzes zu bestimmen, den wir entweder einbetten oder referenzieren möchten. 244 00:11:50,150 --> 00:11:53,320 ‫Und das bedeutet nur, zu analysieren, wie oft Daten in 245 00:11:53,320 --> 00:11:55,282 ‫diesem Datensatz gelesen und geschrieben werden. 246 00:11:55,282 --> 00:11:59,025 ‫Dann schauen wir uns auch etwas an, das ich Datennähe nenne. 247 00:11:59,025 --> 00:12:02,940 ‫Und Datennähe ist ein Begriff, den ich eigentlich gerade erfunden habe, aber 248 00:12:02,940 --> 00:12:06,870 ‫was es bedeutet, ist, wie viel die Daten wirklich miteinander verbunden sind und 249 00:12:06,870 --> 00:12:10,109 ‫wie wir die Daten aus der Datenbank abfragen wollen. 250 00:12:10,109 --> 00:12:11,850 ‫Und das wird mehr 251 00:12:11,850 --> 00:12:14,180 ‫Sinn ergeben, wenn wir gleich darüber sprechen. 252 00:12:14,180 --> 00:12:17,330 ‫Jetzt die Entscheidung treffen; Wir müssen alle diese 253 00:12:17,330 --> 00:12:19,350 ‫drei Kriterien kombinieren und 254 00:12:19,350 --> 00:12:21,792 ‫nicht nur eines davon isoliert verwenden. 255 00:12:21,792 --> 00:12:25,230 ‫Also zum Beispiel; Nur weil Kriterium Nummer eins sagt, dass wir 256 00:12:25,230 --> 00:12:28,380 ‫einbetten sollen, heißt das nicht, dass wir uns die anderen 257 00:12:28,380 --> 00:12:30,425 ‫beiden Kriterien nicht ansehen müssen. 258 00:12:30,425 --> 00:12:34,124 ‫Alles klar und fangen wir mit dem Beziehungstyp an. 259 00:12:34,124 --> 00:12:37,968 ‫Wenn wir also eine zu wenige Beziehung haben, betten wir normalerweise 260 00:12:37,968 --> 00:12:40,700 ‫den zugehörigen Datensatz in den Hauptdatensatz ein, 261 00:12:40,700 --> 00:12:43,430 ‫genau wie wir es auf der letzten 262 00:12:43,430 --> 00:12:45,860 ‫Folie gelernt haben. Rechts. 263 00:12:45,860 --> 00:12:49,110 ‫Jetzt in einer Eins-zu-Viele-Beziehung; Die Dinge sind etwas 264 00:12:49,110 --> 00:12:52,880 ‫unscharfer, daher ist es in Ordnung, entweder einzubetten oder zu verweisen. 265 00:12:52,880 --> 00:12:55,140 ‫In diesem Fall müssen wir nach 266 00:12:55,140 --> 00:12:57,304 ‫den anderen beiden Kriterien entscheiden. 267 00:12:57,304 --> 00:12:59,825 ‫Andererseits beziehen wir uns bei 268 00:12:59,825 --> 00:13:03,894 ‫einer Eins-zu-Tonne- oder einer Viele-zu-Viele-Beziehung normalerweise immer auf 269 00:13:03,894 --> 00:13:06,811 ‫die Daten. Das liegt daran, dass wir 270 00:13:06,811 --> 00:13:10,004 ‫bei einer Einbettung in diesem Fall schnell viel zu große Dokumente erstellen könnten. 271 00:13:10,004 --> 00:13:14,902 ‫Das Maximum von 16 Megabyte wird möglicherweise sogar überschritten. 272 00:13:14,902 --> 00:13:18,214 ‫Die Lösung dafür besteht natürlich darin, die Daten zu 273 00:13:18,214 --> 00:13:22,090 ‫referenzieren oder zu normalisieren. Und als kurzes 274 00:13:22,090 --> 00:13:24,142 ‫Beispiel; Nehmen wir an, in 275 00:13:24,142 --> 00:13:27,830 ‫unserem Filmdatenbankbeispiel sind jedem Film etwa 100 Bilder zugeordnet. 276 00:13:27,830 --> 00:13:30,874 ‫Wir könnten also sagen, es ist eine Eins-zu-Viele-Beziehung, 277 00:13:30,874 --> 00:13:34,230 ‫aber werden wir den Datensatz einbetten oder sollten wir 278 00:13:34,230 --> 00:13:37,523 ‫ihn hier eher referenzieren? Nun, wir wissen es nicht wirklich. 279 00:13:37,523 --> 00:13:40,571 ‫Werfen wir also einen Blick auf die anderen beiden Kriterien. 280 00:13:40,571 --> 00:13:44,420 ‫Beim zweiten geht es also um Datenzugriffsmuster, bei denen es sich 281 00:13:44,420 --> 00:13:46,290 ‫nur um eine ausgefallene 282 00:13:46,290 --> 00:13:48,242 ‫Beschreibung handelt, um zu bewerten, ob 283 00:13:48,242 --> 00:13:51,559 ‫ein bestimmter Datensatz hauptsächlich geschrieben oder hauptsächlich gelesen wird. 284 00:13:51,559 --> 00:13:55,760 ‫Wenn also der Datensatz, für den wir uns entscheiden, hauptsächlich gelesen 285 00:13:55,760 --> 00:13:58,179 ‫wird und die Daten nicht 286 00:13:58,179 --> 00:14:01,620 ‫oft aktualisiert werden, sollten wir diesen Datensatz wahrscheinlich einbetten. 287 00:14:01,620 --> 00:14:04,690 ‫Ein hohes Lese-/Schreibverhältnis bedeutet also nur, dass viel 288 00:14:04,690 --> 00:14:07,100 ‫mehr gelesen als geschrieben wird. 289 00:14:07,100 --> 00:14:11,100 ‫Und wieder ist ein Datensatz wie dieser ein guter Kandidat für 290 00:14:11,100 --> 00:14:11,983 ‫die Einbettung. 291 00:14:12,830 --> 00:14:15,980 ‫Der Grund dafür ist, dass wir durch die Einbettung nur eine 292 00:14:15,980 --> 00:14:18,379 ‫Fahrt in die Datenbank pro Abfrage benötigen. 293 00:14:18,379 --> 00:14:22,197 ‫Für die Referenzierung benötigen wir zwei Fahrten. Rechts. 294 00:14:22,197 --> 00:14:25,660 ‫Wenn wir also Daten einbetten, die viel gelesen werden; 295 00:14:25,660 --> 00:14:28,383 ‫Bei jeder Abfrage sparen wir einen 296 00:14:28,383 --> 00:14:32,147 ‫Weg zur Datenbank, was den gesamten Prozess wesentlich performanter macht. 297 00:14:32,147 --> 00:14:35,260 ‫Daher denke ich, dass unser Filmbild-Beispiel tatsächlich ein 298 00:14:35,260 --> 00:14:38,320 ‫guter Kandidat für die Einbettung wäre. 299 00:14:38,320 --> 00:14:41,543 ‫Denn sobald die 100 Bilder in der Datenbank gespeichert 300 00:14:41,543 --> 00:14:43,920 ‫sind, werden sie nicht mehr wirklich aktualisiert, 301 00:14:43,920 --> 00:14:46,930 ‫da es an einem Bild nicht wirklich etwas 302 00:14:46,930 --> 00:14:50,057 ‫zu aktualisieren gibt. Richtig, es geht 303 00:14:50,057 --> 00:14:52,563 ‫also nur ums Lesen und daher würden 304 00:14:52,563 --> 00:14:55,501 ‫wir anhand dieser Kriterien die abgebildeten Dokumente einbetten. 305 00:14:55,501 --> 00:14:59,092 ‫Wenn unsere Daten jedoch häufig aktualisiert werden, sollten 306 00:14:59,092 --> 00:15:03,118 ‫wir eine Referenzierung oder Normalisierung der Daten in Betracht ziehen. 307 00:15:03,118 --> 00:15:06,700 ‫Das liegt daran, dass die Datenbank-Engine mehr Arbeit benötigt, 308 00:15:06,700 --> 00:15:08,870 ‫um ein Dokument zu aktualisieren 309 00:15:08,870 --> 00:15:11,600 ‫und einzubetten, als ein einfacheres eigenständiges Dokument. 310 00:15:11,600 --> 00:15:13,980 ‫Und da unser Hauptziel Leistung ist; Wir 311 00:15:13,980 --> 00:15:15,917 ‫normalisieren nur den Datensatz. 312 00:15:15,917 --> 00:15:19,653 ‫Sagen wir in unserem Beispiel, dass jeder Film viele Rezensionen hat 313 00:15:19,653 --> 00:15:23,284 ‫und jede Rezension vom Benutzer als hilfreich markiert werden kann. 314 00:15:23,284 --> 00:15:27,560 ‫Jedes Mal, wenn jemand auf diese Bewertung klickt, war für unsere 315 00:15:27,560 --> 00:15:29,780 ‫Anwendung hilfreich. Wir müssen 316 00:15:29,780 --> 00:15:31,740 ‫das entsprechende Dokument aktualisieren. 317 00:15:31,740 --> 00:15:35,030 ‫Und das bedeutet, dass sich die Daten ständig ändern 318 00:15:35,030 --> 00:15:38,520 ‫können, und daher ist dies ein großartiger Kandidat für die Normalisierung. 319 00:15:38,520 --> 00:15:41,420 ‫Nochmals, weil wir nicht die ganze Zeit nach den 320 00:15:41,420 --> 00:15:45,190 ‫Filmen fragen wollen, ob wir wirklich nur die Rezensionen aktualisieren möchten, indem 321 00:15:45,190 --> 00:15:47,230 ‫wir sie als hilfreich markieren. 322 00:15:47,230 --> 00:15:49,464 ‫Okay, macht das Sinn? 323 00:15:49,464 --> 00:15:53,500 ‫Und schließlich die letzten Kriterien, die ich Datennähe nenne; das ist wie 324 00:15:53,500 --> 00:15:56,320 ‫ein Maß dafür, wie sehr die Daten miteinander 325 00:15:56,320 --> 00:15:59,469 ‫in Beziehung stehen. Wenn die 326 00:15:59,469 --> 00:16:02,890 ‫beiden Datensätze also wirklich untrennbar zusammengehören, 327 00:16:02,890 --> 00:16:05,880 ‫sollten sie wahrscheinlich ineinander eingebettet werden. 328 00:16:05,880 --> 00:16:10,440 ‫In unserem Beispiel; Alle Benutzer können viele E-Mail-Adressen in ihrem 329 00:16:10,440 --> 00:16:13,780 ‫Konto haben und da sie so untrennbar 330 00:16:13,780 --> 00:16:17,190 ‫mit dem Benutzer verbunden sind, sollten E-Mails zweifellos 331 00:16:17,190 --> 00:16:19,920 ‫in das Dokument eingebettet werden. 332 00:16:19,920 --> 00:16:23,830 ‫Wenn wir nun häufig beide Datensätze einzeln abfragen müssen, ist 333 00:16:23,830 --> 00:16:26,388 ‫dies ein sehr guter Grund, 334 00:16:26,388 --> 00:16:29,696 ‫die Daten in zwei separate Datensätze zu normalisieren. 335 00:16:29,696 --> 00:16:32,790 ‫Auch wenn sie eng verwandt sind. 336 00:16:32,790 --> 00:16:35,227 ‫Stellen Sie sich also vor, wir haben 337 00:16:35,227 --> 00:16:40,227 ‫in unserer App ein Quiz, bei dem Benutzer einen Film anhand von Bildern identifizieren müssen. 338 00:16:40,440 --> 00:16:43,080 ‫Das bedeutet, dass wir viele Bilder selbst 339 00:16:43,080 --> 00:16:44,180 ‫abfragen werden. 340 00:16:44,180 --> 00:16:47,756 ‫Also ohne unbedingt nach den Filmen selbst zu fragen. 341 00:16:47,756 --> 00:16:50,640 ‫Wenn wir dieses dritte Kriterium anwenden; kommen 342 00:16:50,640 --> 00:16:54,137 ‫wir zu dem Schluss, dass wir den Bilddatensatz eigentlich 343 00:16:54,137 --> 00:16:56,759 ‫normalisieren sollten. Gut. 344 00:16:56,759 --> 00:17:00,770 ‫Denn noch einmal, wenn wir diese Quiz-Funktionalität implementieren; Bilder 345 00:17:00,770 --> 00:17:04,057 ‫werden die ganze Zeit von selbst abgefragt. 346 00:17:04,057 --> 00:17:07,422 ‫All dies zeigt also, dass wir wirklich alle 347 00:17:07,422 --> 00:17:09,850 ‫drei Kriterien zusammen betrachten sollten 348 00:17:09,850 --> 00:17:12,700 ‫und nicht nur eines von ihnen isoliert. 349 00:17:12,700 --> 00:17:15,841 ‫Denn das könnte zu weniger optimalen Entscheidungen führen. 350 00:17:15,841 --> 00:17:18,908 ‫Und ich sage weniger optimal statt falsch, 351 00:17:18,908 --> 00:17:21,766 ‫weil sie nicht wirklich ganz richtig 352 00:17:21,766 --> 00:17:25,262 ‫oder ganz falsch sind, um unsere Daten zu modellieren. 353 00:17:25,262 --> 00:17:28,970 ‫Es gibt keine harten Regeln; Dies sind nur Richtlinien, die Sie befolgen 354 00:17:28,970 --> 00:17:31,380 ‫können, um die wahrscheinlich korrekteste Art 355 00:17:31,380 --> 00:17:33,860 ‫und Weise zu finden, Ihre Daten zu strukturieren. 356 00:17:33,860 --> 00:17:37,077 ‫Aber auch hier ist es schwer, wirklich falsch zu liegen. 357 00:17:37,077 --> 00:17:38,253 ‫Okay? 358 00:17:39,740 --> 00:17:43,110 ‫Nehmen wir nun an, wir haben uns entschieden, unsere 359 00:17:43,110 --> 00:17:44,270 ‫Datensätze zu normalisieren. 360 00:17:44,270 --> 00:17:46,653 ‫Also Referenzdaten. 361 00:17:46,653 --> 00:17:49,380 ‫Danach müssen wir uns 362 00:17:49,380 --> 00:17:52,840 ‫noch zwischen drei verschiedenen Referenzierungsarten entscheiden. 363 00:17:52,840 --> 00:17:55,460 ‫Untergeordnete Referenzierung, Elternreferenzierung und 364 00:17:55,460 --> 00:17:57,540 ‫bidirektionale Referenzierung. 365 00:17:57,540 --> 00:18:00,767 ‫Der erste Typ ist also die untergeordnete Referenzierung. 366 00:18:00,767 --> 00:18:04,440 ‫Welchen Referenzierungstyp habe ich Ihnen zuvor gezeigt. 367 00:18:04,440 --> 00:18:05,470 ‫Okay? 368 00:18:05,470 --> 00:18:07,850 ‫Und nehmen wir nicht das Fehlerprotokollierungsbeispiel, das ich 369 00:18:07,850 --> 00:18:10,128 ‫zuvor erwähnt habe. Wo wir 370 00:18:10,128 --> 00:18:13,021 ‫möglicherweise Millionen von gesperrten Dokumenten haben könnten. 371 00:18:13,021 --> 00:18:17,300 ‫Also beim Verweisen auf Kinder; Wir behalten grundsätzlich Verweise auf die 372 00:18:17,300 --> 00:18:20,460 ‫zugehörigen untergeordneten Dokumente in einem übergeordneten Dokument. 373 00:18:20,460 --> 00:18:22,941 ‫Und sie werden normalerweise in einem Array gespeichert. 374 00:18:22,941 --> 00:18:25,735 ‫Sie sehen also, dass jedes Protokoll eine ID 375 00:18:25,735 --> 00:18:29,040 ‫hat und dann im App-Dokument dieses Array mit all diesen 376 00:18:29,040 --> 00:18:31,358 ‫IDs ist. Rechts? 377 00:18:31,358 --> 00:18:34,400 ‫Das Problem hierbei ist jedoch, dass diese 378 00:18:34,400 --> 00:18:39,320 ‫Reihe von IDs sehr groß werden kann, wenn viele Kinder da sind. 379 00:18:39,320 --> 00:18:42,230 ‫Und dies ist ein Anti-Muster in MongoDB. 380 00:18:42,230 --> 00:18:45,156 ‫Also etwas, das wir um jeden Preis vermeiden sollten. 381 00:18:45,156 --> 00:18:47,660 ‫Außerdem sorgt die Kinderreferenzierung dafür, 382 00:18:47,660 --> 00:18:51,410 ‫dass Eltern und Kinder sehr eng miteinander verbunden sind. 383 00:18:51,410 --> 00:18:54,840 ‫Was nicht immer ideal ist. Aber genau 384 00:18:54,840 --> 00:18:57,020 ‫deshalb haben wir Elternreferenzen. 385 00:18:57,020 --> 00:19:00,300 ‫Also bei der Elternreferenzierung; es funktioniert 386 00:19:00,300 --> 00:19:01,870 ‫eigentlich andersherum. 387 00:19:01,870 --> 00:19:05,570 ‫Hier behalten wir also in jedem untergeordneten Dokument einen Verweis 388 00:19:05,570 --> 00:19:07,430 ‫auf das übergeordnete Element. 389 00:19:07,430 --> 00:19:10,267 ‫Daher der Name Elternreferenz. 390 00:19:10,267 --> 00:19:13,890 ‫In diesem Beispiel ist die App-ID 23 und daher 391 00:19:13,890 --> 00:19:16,640 ‫befindet sich in jedem Protokoll das 392 00:19:16,640 --> 00:19:18,990 ‫App-Feld mit der 23-ID darin. 393 00:19:18,990 --> 00:19:21,660 ‫Damit das Kind seine Eltern immer kennt. 394 00:19:21,660 --> 00:19:24,920 ‫In diesem Fall wissen die Eltern also eigentlich nichts 395 00:19:24,920 --> 00:19:26,080 ‫über die Kinder. 396 00:19:26,080 --> 00:19:28,768 ‫Nicht wer sie sind und nicht wie viele sie sind. 397 00:19:28,768 --> 00:19:32,890 ‫Sie sind also viel isolierter und eigenständiger. 398 00:19:32,890 --> 00:19:35,326 ‫Dabei kann es manchmal von Vorteil sein. 399 00:19:35,326 --> 00:19:38,880 ‫Welcher dieser beiden Typen ist also für diese 400 00:19:38,880 --> 00:19:40,527 ‫Datenbeziehung tatsächlich besser. 401 00:19:40,527 --> 00:19:42,820 ‫Und denken Sie daran, wie ich sagte, dass 402 00:19:42,820 --> 00:19:45,860 ‫es Millionen von Protokollen geben könnte und nehmen wir an, dass 403 00:19:45,860 --> 00:19:47,652 ‫es zwei Millionen protokollierte Dokumente gibt. 404 00:19:47,652 --> 00:19:51,340 ‫Im Fall einer untergeordneten Referenzierung würde dies bedeuten, 405 00:19:51,340 --> 00:19:53,209 ‫dass das App-Dokument 406 00:19:53,209 --> 00:19:55,091 ‫zwei Millionen ID-Referenzen enthält. 407 00:19:55,091 --> 00:19:58,300 ‫Rechts? Denken Sie jetzt auch daran, wie ich 408 00:19:58,300 --> 00:20:00,545 ‫gesagt habe, dass für Dokumente eine Beschränkung von 16 Megabyte gilt. 409 00:20:00,545 --> 00:20:04,302 ‫Wenn wir also diese untergeordneten IDs weiterhin zum Array auf dem 410 00:20:04,302 --> 00:20:06,716 ‫übergeordneten Element hinzufügen und hinzufügen; dann würden 411 00:20:06,716 --> 00:20:09,575 ‫wir ziemlich schnell die Grenze von 16 Megabyte erreichen, 412 00:20:09,575 --> 00:20:11,772 ‫die jedes Bson-Dokument aufnehmen kann. 413 00:20:11,772 --> 00:20:14,702 ‫Einfach, weil dieses Array so stark wachsen wird. 414 00:20:14,702 --> 00:20:17,210 ‫Das wird also nicht wirklich funktionieren. 415 00:20:17,210 --> 00:20:18,510 ‫Ist es? 416 00:20:18,510 --> 00:20:20,590 ‫Auf der anderen Seite wird dieses 417 00:20:20,590 --> 00:20:22,990 ‫Problem nicht auftreten, wenn die Eltern darauf verweisen. 418 00:20:22,990 --> 00:20:25,570 ‫Wir werden einfach wie zuvor zwei 419 00:20:25,570 --> 00:20:30,540 ‫Millionen gesperrte Dokumente haben, aber jedes von ihnen hat die ID seines Elternteils. 420 00:20:30,540 --> 00:20:33,098 ‫Aber es gibt kein Array, 421 00:20:33,098 --> 00:20:35,740 ‫das auf unbestimmte Zeit wächst, und daher 422 00:20:35,740 --> 00:20:38,443 ‫wäre eine Elternreferenzierung hier die beste Lösung. 423 00:20:39,380 --> 00:20:41,901 ‫Die Schlussfolgerung aus all dem ist, dass die Bezugnahme 424 00:20:41,901 --> 00:20:44,385 ‫auf Kinder im Allgemeinen am besten für eine 425 00:20:44,385 --> 00:20:48,008 ‫bis wenige Beziehungen verwendet wird. Wobei wir im Voraus wissen, 426 00:20:48,008 --> 00:20:51,118 ‫dass die Anzahl der untergeordneten Dokumente nicht so stark anwachsen wird. 427 00:20:51,118 --> 00:20:54,573 ‫Auf der anderen Seite wird die Elternreferenzierung 428 00:20:54,573 --> 00:20:58,690 ‫am besten für Eins-zu-Viele- und Eins-zu-Tonnen-Beziehungen wie diese 429 00:20:58,690 --> 00:21:00,927 ‫verwendet. Okay? 430 00:21:00,927 --> 00:21:04,610 ‫Denken Sie also immer daran, dass eines 431 00:21:04,610 --> 00:21:07,920 ‫der wichtigsten Prinzipien der MongoDB-Datenmodellierung 432 00:21:07,920 --> 00:21:11,900 ‫darin besteht, dass Arrays niemals unbegrenzt wachsen dürfen. 433 00:21:11,900 --> 00:21:15,420 ‫Um diese 16-Megabyte-Grenze nie zu überschreiten. 434 00:21:15,420 --> 00:21:18,170 ‫Wir möchten unseren Benutzern auch nicht jedes Mal ein 435 00:21:18,170 --> 00:21:20,730 ‫Array mit Tausenden von IDs senden, wenn sie 436 00:21:20,730 --> 00:21:24,340 ‫einen übergeordneten Datensatz anfordern. Okay? 437 00:21:24,340 --> 00:21:26,900 ‫War diese Logik für Sie sinnvoll? 438 00:21:26,900 --> 00:21:29,660 ‫Gehen wir dann zum dritten Referenzierungstyp über, 439 00:21:29,660 --> 00:21:31,870 ‫der eine bidirektionale Referenzierung ist. 440 00:21:31,870 --> 00:21:34,395 ‫Und dieses Mal mit dem Film- und Schauspielerbeispiel, das 441 00:21:34,395 --> 00:21:36,380 ‫ich Ihnen gezeigt habe, als wir über 442 00:21:36,380 --> 00:21:39,364 ‫viele zu viele Beziehungen sprachen. Erinnere dich daran? 443 00:21:39,364 --> 00:21:42,229 ‫Auch hier hat jeder Film viele Schauspieler und 444 00:21:42,229 --> 00:21:44,880 ‫jeder Schauspieler spielt in vielen Filmen. 445 00:21:44,880 --> 00:21:48,464 ‫Das ist also eine typische Viele-zu-Viele-Beziehung. 446 00:21:48,464 --> 00:21:52,100 ‫Und normalerweise verwenden wir diese bidirektionale Referenzierung, um viele zu 447 00:21:52,100 --> 00:21:55,346 ‫viele Beziehungen zu entwerfen. Und es funktioniert 448 00:21:55,346 --> 00:21:59,370 ‫so; In jedem Film werden wir Verweise auf alle Schauspieler 449 00:21:59,370 --> 00:22:03,980 ‫behalten, die in diesem Film mitspielen. Also ein bisschen wie bei der Referenzierung von Kindern. 450 00:22:03,980 --> 00:22:07,000 ‫Gleichzeitig halten wir in jedem Schauspieler jedoch auch 451 00:22:07,000 --> 00:22:09,570 ‫Verweise auf alle Filme, in denen 452 00:22:09,570 --> 00:22:11,660 ‫der Schauspieler mitgespielt hat. 453 00:22:11,660 --> 00:22:15,120 ‫Filme und Schauspieler sind also in beide Richtungen verbunden. 454 00:22:15,120 --> 00:22:17,900 ‫Daher der Name bidirektionale Referenzierung. 455 00:22:17,900 --> 00:22:19,950 ‫Und das macht es wirklich einfach, 456 00:22:19,950 --> 00:22:23,290 ‫sowohl nach Filmen als auch nach Schauspielern völlig unabhängig zu suchen. 457 00:22:23,290 --> 00:22:25,910 ‫Gleichzeitig ist es einfach, die jedem 458 00:22:25,910 --> 00:22:29,029 ‫Film zugeordneten Schauspieler und die jedem Schauspieler zugeordneten 459 00:22:29,029 --> 00:22:30,383 ‫Filme zu finden. 460 00:22:31,623 --> 00:22:32,560 ‫(tiefer Atemzug) 461 00:22:32,560 --> 00:22:34,747 ‫Das war wirklich ein ziemlich langer Vortrag. 462 00:22:34,747 --> 00:22:38,030 ‫Mit vielen neuen Konzepten und Prinzipien und Richtlinien, 463 00:22:38,030 --> 00:22:40,220 ‫die man sich merken sollte. 464 00:22:40,220 --> 00:22:43,460 ‫Um Ihnen dabei zu helfen; Hier ist eine kurze 465 00:22:43,460 --> 00:22:46,650 ‫Zusammenfassung und einige allgemeinere Richtlinien, die Sie sich 466 00:22:46,650 --> 00:22:48,423 ‫bei Bedarf ansehen können. 467 00:22:49,260 --> 00:22:52,753 ‫Das wichtigste Prinzip lautet also: Strukturieren Sie Ihre Daten so, dass 468 00:22:52,753 --> 00:22:56,120 ‫sie der Art und Weise entsprechen, wie Ihre Anwendung Daten 469 00:22:56,120 --> 00:22:57,436 ‫abfragt und aktualisiert. 470 00:22:57,436 --> 00:23:01,400 ‫Oder anders ausgedrückt: Identifizieren Sie zuerst die Fragen, die sich aus 471 00:23:01,400 --> 00:23:03,784 ‫den Anwendungsfällen Ihrer Anwendung ergeben, und 472 00:23:03,784 --> 00:23:06,634 ‫modellieren Sie dann Ihre Daten, damit die Fragen 473 00:23:06,634 --> 00:23:08,995 ‫möglichst effizient beantwortet werden können. 474 00:23:08,995 --> 00:23:12,610 ‫Zum Beispiel; wenn ich Filme und Schauspieler immer zusammen abfragen 475 00:23:12,610 --> 00:23:16,130 ‫muss oder es Szenarien gibt, in denen ich nur Filme 476 00:23:16,130 --> 00:23:18,041 ‫oder nur Schauspieler abfrage. 477 00:23:18,041 --> 00:23:20,528 ‫Auf solchen Fragen basiert 478 00:23:20,528 --> 00:23:22,930 ‫Ihr Datenmodell. 479 00:23:22,930 --> 00:23:26,730 ‫Im Allgemeinen sollten Sie das Einbetten immer bevorzugen, es sei denn, es gibt einen 480 00:23:26,730 --> 00:23:28,440 ‫guten Grund, es nicht einzubetten. 481 00:23:28,440 --> 00:23:32,513 ‫Vor allem bei einer zu wenigen und einer zu vielen Beziehungen. 482 00:23:33,370 --> 00:23:37,713 ‫Als nächstes ist eine Eins-zu-Tonnen- oder eine Viele-zu-Viele-Beziehung normalerweise ein guter 483 00:23:37,713 --> 00:23:41,543 ‫Grund, auf eine Referenz zu verweisen, anstatt sie einzubetten. 484 00:23:41,543 --> 00:23:45,734 ‫Bevorzugen Sie auch die Referenzierung, wenn Daten häufig 485 00:23:45,734 --> 00:23:50,717 ‫aktualisiert werden und Sie häufig allein auf einen Datensatz zugreifen müssen. 486 00:23:50,717 --> 00:23:55,340 ‫Verwenden Sie die Einbettung, wenn Daten hauptsächlich gelesen, aber selten aktualisiert 487 00:23:55,340 --> 00:23:58,469 ‫werden und wenn zwei Datensätze untrennbar zusammengehören. 488 00:23:58,469 --> 00:24:02,840 ‫Lassen Sie Arrays nicht unbegrenzt wachsen. 489 00:24:02,840 --> 00:24:05,982 ‫Wenn Sie daher normalisieren möchten; Verwenden 490 00:24:05,982 --> 00:24:09,680 ‫Sie die untergeordnete Referenzierung für 1-zu-viele-Beziehungen und 491 00:24:09,680 --> 00:24:11,856 ‫die Elternreferenzierung für 1-zu-viele-Beziehungen. 492 00:24:11,856 --> 00:24:15,160 ‫Und schließlich verwenden Sie die bidirektionale Referenzierung 493 00:24:15,160 --> 00:24:17,520 ‫für viele zu viele Beziehungen. 494 00:24:17,520 --> 00:24:18,720 ‫Gut? 495 00:24:18,720 --> 00:24:21,202 ‫Und das fasst es ziemlich gut zusammen. 496 00:24:21,202 --> 00:24:23,970 ‫Ich würde Ihnen sogar empfehlen, sich dieses 497 00:24:23,970 --> 00:24:27,144 ‫Video nach Möglichkeit zweimal anzusehen, nur weil dieses Material 498 00:24:27,144 --> 00:24:30,091 ‫wirklich wichtig ist. Gut? 499 00:24:30,091 --> 00:24:33,363 ‫Wie auch immer, wir sehen uns im nächsten Video.