Ich versuche, MongoDB, C # und NoRM zu verwenden, um an einigen Beispielprojekten zu arbeiten, aber an diesem Punkt habe ich es ist viel schwieriger, meinen Kopf um das Datenmodell zu wickeln. Mit RDBMS verbundene Daten sind kein Problem. In MongoDB fällt es mir jedoch schwer zu entscheiden, was ich mit ihnen machen soll.
Lassen Sie uns StackOverflow als Beispiel nehmen ... Ich habe kein Problem zu verstehen, dass die Mehrheit der Daten auf einer Frage-Seite in einem Dokument enthalten sein sollte. Titel, Fragetext, Revisionen, Kommentare ... alles in einem Dokumentobjekt.
Wo ich trübe werde, ist die Frage nach Benutzerdaten wie Benutzername, Avatar, Reputation (was sich besonders oft ändert) ... Denormalisieren und aktualisieren Sie jedes Mal tausende von Dokumentensätzen ist ein Benutzerwechsel oder verknüpfen Sie die Daten irgendwie miteinander?
Was ist der effizienteste Weg, um eine Benutzerbeziehung zu erreichen, ohne dass bei jedem Laden der Seite Unmengen von Abfragen auftreten? Ich habe den Typ DbReference<T> in NoRM bemerkt, aber noch keine gute Möglichkeit gefunden, ihn zu benutzen. Was ist, wenn ich wahlfreie NULL-Beziehungen haben darf?
Danke für Ihre Einsicht!
Die Waage, die ich gefunden habe, verwendet SQL als normalisierte Datenbank und Mongo als denormalisierte Kopie. Ich benutze einen ESB, um sie synchron zu halten. Ich verwende ein Konzept, das ich "vorbereitete Dokumente" und "gespeicherte Dokumente" nenne. Gespeicherte Dokumente sind Daten, die nur in Mongo aufbewahrt werden. Nützlich für Daten, die nicht relational sind. Die vorbereiteten Dokumente enthalten Daten, die mithilfe der Daten in der normalisierten Datenbank neu erstellt werden können. Sie fungieren gewissermaßen als lebende Caches - sie können von Grund auf neu erstellt werden, wenn die Daten jemals nicht synchron sind (in komplizierten Dokumenten ist dies ein teurer Prozess, da für diese Dokumente viele Abfragen neu erstellt werden müssen). Sie können auch jeweils ein Feld aktualisiert werden. Hier kommt der Servicebus ins Spiel. Er reagiert auf Ereignisse, die gesendet werden, nachdem die normalisierte Datenbank aktualisiert wurde, und aktualisiert dann die relevanten mongo-vorbereiteten Dokumente.
Verwenden Sie jede Datenbank zu ihren Stärken. Zulassen, dass SQL die Schreibdatenbank ist, die die Datenintegrität gewährleistet. Lassen Sie Mongo die schreibgeschützte Datenbank sein, die blitzschnell ist und Unterdokumente enthalten kann, so dass Sie weniger Abfragen benötigen.
** BEARBEITEN ** Ich habe deine Frage noch einmal gelesen und erkannt, wonach du eigentlich gefragt hast. Ich lasse meine ursprüngliche Antwort für den Fall, dass es überhaupt hilfreich ist.
Die Art und Weise, wie ich das von Ihnen angegebene Stackoverflow-Beispiel behandeln würde, besteht darin, die Benutzer-ID in jedem Kommentar zu speichern. Du würdest den Beitrag laden, der alle Kommentare enthalten würde. Das ist eine Abfrage.
Sie würden dann die Kommentardaten durchlaufen und ein Array von Benutzer-IDs herausziehen, die Sie laden müssen. Laden Sie diese anschließend als Stapelabfrage (mithilfe des Abfrageoperators Q.In ()). Das sind zwei Abfragen insgesamt. Sie müssten dann die Daten zu einer endgültigen Form zusammenführen. Es gibt ein Gleichgewicht, zwischen dem Sie entscheiden müssen, wann Sie das tun sollen und wann Sie etwas wie einen ESB verwenden müssen, um jedes Dokument manuell zu aktualisieren. Verwenden Sie, was am besten für jedes einzelne Szenario Ihrer Datenstruktur funktioniert.
Warum möchten Sie Denormalisierung vermeiden und Tausende von Dokumentensätzen aktualisieren? Mongodb db zur Denormalisierung konzipiert. Stackoverlow behandelt Millionen von verschiedenen Daten im Hintergrund. Und einige Daten können für eine kurze Zeit veraltet sein und es ist in Ordnung.
Der Grundgedanke des oben Gesagten ist, dass Sie denormalisierte Dokumente haben sollten, um sie schnell in ui anzeigen zu können.
Sie können nicht nach referenziertem Dokument suchen, in irgendeiner Weise, die Sie benötigen Denormalisierung.
Ich schlage auch vor, dass Sie sich die Architektur von cqrs ansehen.
Versuchen Sie, die Architektur von cqrs und Event Sourcing zu untersuchen. Dadurch können Sie alle diese Daten nach Warteschlange aktualisieren.
Tags und Links c# mongodb mongodb-.net-driver norm denormalization