Bitte entschuldigen Sie mein Englisch, ich versuche immer noch, es zu meistern.
Ich habe begonnen, MongoDB zu lernen (kommt aus einem C # -Hintergrund), und mir gefällt die Idee, was MongoDB ist. Ich habe einige Probleme mit Beispielen im Internet.
Nehmen Sie das beliebte Blogpost / Kommentare Beispiel. Post hat keine oder viele damit verbundene Kommentare. Ich erstelle Post-Objekt, füge einige Kommentar-Objekte zur IList in Post hinzu. Das ist in Ordnung.
Füge ich das nur zu einer "Posts" -Sammlung in MonoDB hinzu oder sollte ich zwei Sammlungen haben - eine ist blog.posts und blog.posts.comments?
Ich habe ein faires kompliziertes Objektmodell, die einfachste Art, es als ein Banking-System zu betrachten - unser Bergbau. Ich habe versucht, Tabellen mit eckigen Klammern hervorzuheben.
[Nutzer] haben einen oder mehrere [Accounts] mit einer oder mehreren [Transaktionen] , die nur einen haben > [Typ] . [Transaktionen] kann der Transaktion einen oder mehrere [Tag] zugewiesen haben. [Nutzer] erstellen eigene [Tags] , die nur für diesen Nutzeraccount gelten, und manchmal müssen wir die Berichterstellung für diese Tags anbieten (z. B. für den Monat Mai waren die Drilling-Ausgaben $ 123456,78 ).
Für die Indexierung hätte ich gedacht, sie zu trennen wäre gut, aber ich mache mir Sorgen, dass es schlecht ist, dieses Denken aus alten RBDMS-Tagen zu praktizieren.
In gewisser Weise ist es wie im Blog-Beispiel. Ich bin mir nicht sicher, ob ich 1 [Konto] Sammlung haben und alle Informationen dort beibehalten oder einen Zwischenschritt haben soll, der es in separate Sammlungen aufteilt.
Die andere verwandte Abfrage ist, wenn Sie hin und her persistieren, normalerweise alles , das mit diesem Datensatz verbunden ist - auch wenn es nicht erforderlich ist oder Sie begrenzen?
Es kommt darauf an.
Es hängt davon ab, wie viele dieser Objekte Sie erwarten. Können Sie alle für ein bestimmtes Benutzerkonto in ein MongoDB-Dokument einfügen? Wahrscheinlich nicht.
Es hängt von den Beziehungen ab - ist der Benutzer-Account eine Eins-zu-Viele- oder eine Viele-zu-Viele-Beziehung? Wenn es sich um eins zu viele handelt und die Anzahl der Konten gering ist, können Sie sie in eine IList in einem Benutzerdokument einfügen.
Sie können Beziehungen in MongoDB immer noch mit separaten Sammlungen modellieren, aber es gibt keine Joins in der Datenbank, daher müssen Sie dies im Code tun. Das Laden eines Benutzers und das anschließende Laden der Benutzerkonten ist aus Leistungsperspektive möglicherweise problemlos möglich.
Sie können INTO-Arrays für Dokumente indizieren. Stellen Sie sich einen Index nicht als einen Index für ein einfaches Feld in einem Dokument vor (wie SQL). Sie können zum Beispiel eine Tag-Sammlung in einem Dokument verwenden und in die Tags indexieren. (Siehe Ссылка )
Wenn Sie Daten abrufen oder schreiben, können Sie jedes Dokument teilweise lesen und teilweise schreiben. (Siehe Ссылка )
Und schließlich, wenn Sie nicht sehen können, wie Sie mit Sammlungen und Indizes das bekommen, was Sie wollen, können Sie es mit map reduce erreichen. Um beispielsweise alle derzeit verwendeten Tags sortiert nach ihrer Nutzungshäufigkeit zu finden, würden Sie jedes Dokument zuordnen, das die darin verwendeten Tags ausgibt, und dann reduzieren diesen Satz um das gewünschte Ergebnis zu erhalten. Sie können dann das Ergebnis dieser Karte dauerhaft speichern und nur dann aktualisieren, wenn es nötig ist.
Ein weiteres Problem: Sie erwähnen die Berechnung von Summen nach Tag. Wenn Sie transaktionale Konsistenz in Buchhaltungsqualität wünschen, ist MongoDB möglicherweise nicht die richtige Wahl für Sie. "Eventual-Consistency" heißt das Spiel für NoSQL-Data-Stores und eignet sich im Allgemeinen nicht für Finanztransaktionen. Es ist beispielsweise egal, ob ein Benutzer einen Blogbeitrag mit 3 Kommentaren sieht, während ein anderer Nutzer 4 sieht, da sie auf verschiedene Kopien stoßen, die noch nicht synchron sind. Für einen Finanzbericht ist diese Art von Konsistenz jedoch von Bedeutung Bericht könnte nicht summieren!
Tags und Links c# model-view-controller winforms mongodb database-design