(MUSIK)
Ich schätze, dein Kopf ist von Mungos befallen oder ist es Mongeese?
Nun, ich bin kein Englisch-Major, also habe ich keine Ahnung, was der Plural ist.
Auf jeden Fall bringt uns das zum Thema dieser Vorlesung, Mungo Bevölkerung.
Was genau ist Mongoose Bevölkerung und
wie ist es nützlich in unserer Express-Anwendung?
Lass uns als Nächstes darüber reden.
Wie wir erkannt haben,
sind Dokumentdatenbanken, die NoSQL-Datenbanken, nicht mit Relationen im Auge.
Alles, was Sie in einem Dokument benötigen, wird vollständig im Dokument gespeichert.
Nun, das ist so ziemlich die Art, wie die Dinge mit NoSQL-Datenbanken wie MongoDB arbeiten.
Sie haben also keine Unterstützung für Beziehungen, die Sie
aus der relationalen Datenbankwelt besser kennen könnten.
Wo Sie Datensätze haben und dann Datensätze können auf andere Datensätze verweisen und so weiter.
Und dann tun Sie Joins, um die Informationen aus den Datensätzen zu verbinden und so weiter.
Diese Art von Unterstützung existiert also nicht in NoSQL-Datenbanken,
zumindest zu einem großen Teil.
MongoDB hat einige Schritte in diese Richtung unternommen, sogar mit den NoSQL-Datenbanken.
Im Allgemeinen erwarten Dokumentdatenbanken jedoch, dass alle Dokumente in sich geschlossen sind.
Das bedeutet also, dass sich alle erforderlichen Informationen innerhalb desselben Dokuments befinden.
Nun gibt es natürlich Situationen, in denen Sie andere Dokumente haben, die
bereits die Informationen enthalten.
Möglicherweise möchten Sie diese Informationen in Ihr vorhandenes Dokument abrufen,
anstatt diese Informationen zu duplizieren.
Dies ist also, wo MongoDB oder Mongoose,
ermöglicht es Ihnen, Verweise auf andere Dokumente in einem aktuellen Dokument zu speichern.
Der Verweis auf das andere Dokument erfolgt mithilfe der ObjectID des
anderen Dokuments.
Nun, wenn das der Fall ist, dann können Sie Mongoose eine Möglichkeit durchführen,
die Informationen aus dem anderen Dokument zu nehmen und dann in das
richtige Dokument einzufügen, indem Sie die Mungo Populationsunterstützung verwenden.
Das ist es, was wir noch ein wenig ausführlicher diskutieren werden.
Mongoose selbst, wie wir erkennen, ein Modul, das
auf MongoDB gebaut ist, hat keine explizite Unterstützung für
Joins, die Art und Weise, wie wir über Joins in der SQL-Welt sprechen.
Um zu verstehen, wie uns diese Referenz auf das andere Dokument in einem Dokument hilft und
wie es tatsächlich strukturiert ist, werfen wir einen Blick auf ein Beispiel.
In diesem Beispiel werden wir uns das Geschirr Dokument ansehen, das wir
in unserer Übung verwendet haben.
In den Geschirr Dokumenten, die wir auf der Serverseite speichern,
haben wir bemerkt, dass wir auch die Kommentare speichern.
Und innerhalb der Kommentare speichern wir auch ein Autorenfeld innerhalb der Kommentare.
Und Autorenfeld enthält explizit den Namen der Person, die
diesen bestimmten Kommentar eingereicht hat.
Nun, da wir bereits ein Benutzerdokument
in unserer Datenbank haben, wie wir in diesem Modul gesehen haben.
Wir hatten unseren Experten-Server erweitert, um Benutzer zu unterstützen und damit
können Sie einen Benutzer registrieren und Benutzer authentifizieren und so weiter.
So kann das Benutzerdokument bereits zusätzliche Informationen über den Benutzer enthalten.
Und wenn ein Kommentar vom Benutzer gepostet wird,
anstatt den Namen des Benutzers innerhalb des Kommentars selbst zu speichern,
warum nicht einen Verweis auf den bestimmten Benutzer haben, der den Kommentar gepostet hat?
Dies ist nicht nur im Hinblick auf
die Tatsache hilfreich, dass dieser Kommentar vom jeweiligen Benutzer gepostet wird.
Später werden wir sehen, dass Sie, wenn Sie Benutzern erlauben müssen
, Dokumente zu ändern oder zu löschen, die Art der
Operation eines bestimmten Benutzers nur auf die Kommentare beschränken möchten
, die dieser bestimmte Benutzer zuvor gepostet hat.
Obwohl wir Unterdokumente innerhalb unseres Mongo-Dokuments verwenden.
Wenn wir ein anderes Dokument im Unterdokument mit ObjectIDs
referenzieren können, hilft Mongo uns, diese
Informationen aus dem anderen Dokument in das aktuelle Dokument zu füllen.
Das ist, wo die Mongoose Bevölkerung zu unserer Rettung kommt.
Um diese Idee weiter zu nehmen, lassen Sie mich Ihnen ein detailliertes
Beispiel aus dem Kommentarschema zeigen, das wir zuvor definiert haben.
So haben wir im CommentSchema bereits das Bewertungsfeld und
das Kommentarfeld, das wir dort bereits angegeben haben.
Früher hatten wir auch das Autorenfeld früher.
Für das Autorenfeld früher, wir speichern den Autor
als String und, Der Standardwert auch für den Autor.
Jetzt beim Speichern des Autors als Typzeichenfolge, wenn wir nun
den Autor in eine Art von Mongoose.Schema.Types.ObjectID verwandeln.
Das bedeutet, dass das Autorenfeld jetzt eine ObjectID enthält,
die ein Verweis auf ein Benutzerdokument ist.
Wie stellen Sie sicher, dass dies auf ein Benutzerdokument verweist?
Dies ist also, wo diese zusätzliche Eigenschaft namens ref, die angibt, dass
das Schema des Dokuments, auf das Sie sich hier beziehen, von dem Typ, dem Benutzer, dem
Schema und dem Modell, das wir bereits früher hinzugefügt haben, ist.
In diesem Fall wird das Kommentarschema nun erweitert, um die Autoreninformationen zu speichern,
aber die Autoreninformationen sind in Form einer ObjectID.
Dies ist ein Verweis auf das Benutzerdokument, das bereits in unserer Datenbank gespeichert ist.
Nun, wie hilft uns das?
Dies ist, wo, wie ich sagte, Mongoose Bevölkerung kommt zu unserer Hilfe.
Wie funktioniert die Mungo Bevölkerung?
Bei der Mungo Population besteht die Art und Weise, wie Mongoose Population funktioniert,
darin, dass bestimmte Pfade innerhalb eines aktuellen Dokuments automatisch ersetzt werden.
Das hat Verweis auf ein anderes Dokument durch die Informationen aus diesem anderen Dokument.
So haben Sie im Kommentarschema beispielsweise ein Autorenfeld, das
sich auf die ObjectID des Benutzerdokuments bezieht, das sich bereits in Ihrer Datenbank befindet.
Wenn Sie also Mongoose bitten, dieses Gericht zu füllen,
werden die Informationen über den Autor im Kommentarfeld
aus dem Benutzerdokument aufgefüllt.
So werden die Informationen über den spezifischen Autor, auf den dort verwiesen wird,
abgerufen und in Ihr Gericht Dokument hinzugefügt.
Und das zusammengesetzte Dokument wird erstellt und dann an Sie zurückgeschickt.
Wie stellen wir sicher, dass dies geschieht?
Hier hilft uns dieser Querverweis mit der ObjectID, wie wir gesehen haben.
Wie passiert die Bevölkerung tatsächlich im Code?
Werfen Sie einen Blick darauf, wie wir bevölkern würden, zum
Beispiel, das Geschirr Dokument, das wir gerade zuvor gesehen haben.
Früher waren wir Gerichte zu tun.Finden Sie alle Gerichte in unserer Datenbank zu finden.
Jetzt, wenn Sie das Dishes Dokument gefunden haben, dann können Sie sagen, füllen.
Und geben Sie dann innerhalb des Auffüllens als Parameter
das spezifische Feld an, das ausgefüllt werden muss.
Also hier spezifizieren wir comments.author.
Nun ist die Erwartung, dass das Feld comments.author
tatsächlich eine OjectID ist, die auf das Benutzerdokument verweist.
Und so haben wir bereits unser Kommentarschema eingerichtet.
Also dieser Auffüllen Aufruf, den wir hier ausführen, wird dann gehen und
holen aus der Datenbank jeden einzelnen Autorendatensatz oder den Datensatz des Benutzers.
Und dann nehmen Sie dieses Benutzerdokument und
füllt es in das Geschirr Dokument, um das zusammengesetzte Dokument von hier aus zu konstruieren.
Und dann, natürlich,
gibt es einige nachfolgende Behandlung von Daten, die Sie erhalten haben.
Und dann kann die Antwort oder Rückgabe der Daten an den Client an dieser Stelle erfolgen.
Aber natürlich, lassen Sie mich Sie warnen, dass diese Populationsoperation
keine einfache Aufgabe für den Server ist.
Weil jedes einzelne Gericht, müssen Sie jeden einzelnen Kommentar zu untersuchen.
Dann müssen Sie für jeden Kommentar ihre ObjectID für
den Benutzer herausfinden.
Dann rufen Sie dieses Benutzerdokument ab und
füllen es dann innerhalb des Dish-Dokuments.
Und dann muss das für
jeden einzelnen Kommentar wiederholt werden, der in diesem Dishes Dokument enthalten ist.
Es bedeutet im Wesentlichen, dass es viel länger dauern wird,
bis die Serverseite die Anfrage abschließt und die Informationen an die Clientseite zurücksendet.
Also würde ich vorschlagen, dass Sie Populate sehr vernünftig verwenden sollten.
Sie sollten es nur unter Umständen verwenden, in denen Sie diese Informationen wirklich benötigen.
Wenn Sie zum Beispiel einfach das Menü für Ihr Restaurant erstellen.
Wenn Sie nur das Menü für Ihr Restaurant erstellen,
müssen Sie möglicherweise nicht wirklich die Informationen über den Autor jedes
Kommentars in das Kommentardokument überhaupt eingeben.
Denn wenn Sie gerade das Menü für Ihr Restaurant rendern,
werden Sie nicht die Kommentare für dieses spezielle Gericht zeigen.
Wenn der Benutzer jedoch ein bestimmtes Gericht untersucht und
die Kommentare zu diesem Zeitpunkt sehen möchte,
möchten Sie möglicherweise eine serverseitige Anfrage ausführen.
Und dann holen Sie die Kommentarinformationen mit den anderen
Autoreninformationen in und erhalten Sie diese für die Verwendung innerhalb unserer Kundenseite.
Also wieder, füllen ist eine wunderbare Art, Dinge zu tun, wenn erforderlich,
aber verwenden Sie es sehr gerichtlich, nur wenn Sie wirklich die Informationen benötigen. Die
Flexibilität, die
uns bevölkert, ist also die Tatsache, dass wir nicht bevölkern müssen, wenn wir es nicht müssen.
Aber wir können die Informationen füllen, wenn wir diese Informationen wirklich brauchen.
Mit diesem schnellen Verständnis der Mongoose Bevölkerung,
lassen Sie uns zu der Übung gehen, wo wir das Schemas Gerichte ändern,
das Kommentarschema innerhalb des Schemas Gerichte.
Und dann verwenden Sie Mongoose Populate, um die Informationen innerhalb unserer Gerichte zu füllen,
wenn wir die Gerichteninformationen auf die Serverseite zurückgeben.
Dies bedeutet auch, dass, wenn ein Kommentar zu einem bestimmten Gericht hinzugefügt wird,
der Autor der Informationen des Kommentars auf der Serverseite erfasst werden muss.
Nun kommt es so vor, dass wir auf die Art und Weise, wie
wir unsere Server entwickelt haben, bereits diese Informationen für uns zur Verfügung gestellt werden.
Wenn wir den Benutzer authentifizieren, werden die Informationen des Benutzers bereits in jede
Anfrage geladen, die von der Client-Seite eingeht.
Und so verwenden sie diese Benutzerinformationen, die uns zur Verfügung stehen.
Wenn wir also den Kommentar auf der Serverseite veröffentlichen, werden wir auch die
ID des Benutzers erfassen und sie dann im Autorenfeld des Kommentarschemas speichern.
Dies sollte automatisch auf der Serverseite erfolgen.
Der Kunde darf das Autorenfeld nicht explizit ausfüllen.
Aber die Serverseite sollte den Benutzer validieren und nur für
Benutzer, die angemeldet sind, würden Sie ihnen erlauben, zunächst Kommentare zu posten.
Und wenn sie Kommentare veröffentlichen,
füllen Sie automatisch das Autorenfeld für dieses Kommentardokument aus,
indem Sie das Autorenfeld durch die ObjectID des Benutzers ersetzen.
Nun, in der Übung, werden Sie sehen, wie ich das tue.
Also achten Sie auf diese spezifische Sache in der Übung. Damit
schließen wir diesen Vortrag ab,
lassen Sie uns mit der Übung fortfahren, um die Verwendung von Mungo Population zu untersuchen.
( MUSIK)