Nicht immer führt eine Normalisierung bis zum Tod zu Leistungseinbußen, aber es stimmt, dass ich persönlich nicht dieselbe Normalisierung auf MongoDB anwende wie auf SQL.
Wenn Ihnen die normalisierten Formen bekannt sind ( http://en.wikipedia.org/wiki/Database_normalization ) Ich stelle mir gerne vor, dass MongoDB zu 1NF geht und dann wieder zurück zur Denormalisierung geht.
Oh ja, das tun wir. Das Aktualisieren ist mühsam, wenn die Daten falsch dupliziert werden.
Lassen Sie mich Ihnen ein Beispiel geben:category und product zwei getrennte Einheiten wären, das lässt sich nicht leugnen. Diese beiden Entitäten sind normalisiert (die sich wiederholenden Daten von product wurde von category getrennt ). Eine andere Denkweise ist:Werden alle Produkte nur in einer Kategorie existieren?
Wie Sie sehen können, gelten also für Entitäten der obersten Ebene relativ dieselben Regeln, wobei 1NF problemlos auf MongoDB angewendet werden kann.
Vor dem Hintergrund der Duplizierung möchten Sie natürlich nicht jedes Produkt separat innerhalb jeder Kategorie speichern (ich habe die obige Frage mit Nein beantwortet), also möchten Sie natürlich Kategorien und Produkte trennen.
Normalerweise hätten Sie hier eine Viele-zu-Viele-Beziehung mit einer mittleren normalisierten Tabelle. Hier kann die Denormalisierung ins Spiel kommen. Sie können sagen, dass eine Kategorie eine Liste von Produkten enthält, die für diese Kategorie einzigartig sind, sodass Sie die relationale Viele-zu-Viele-Tabelle als Liste in die Kategoriezeile denormalisieren könnten (oder umgekehrt in die Produktzeile). Dies wird keine Duplizierung erzeugen, da diese Liste für diese Kategorie einzigartig ist (höchstwahrscheinlich). Das bedeutet natürlich, dass die Kategorie oder die Produkte eine Liste _id beinhalten würden s der zugehörigen Zeile anstelle des Objekts selbst.
Es gibt Zeiten, in denen eine Duplizierung erforderlich ist, hauptsächlich zur Optimierung oder zur Umgehung, wenn keine JOINs vorhanden sind. Diese Regel gilt auch für SQL, wenn Sie jemals eine Website erstellt haben, die groß genug ist.
Typische Nutzungsszenarien der Duplizierung sind Aggregationsfelder von Statistiken wie Facebook-Posts, Shares und Kommentare, und vielleicht würden sogar die 5 neuesten Kommentare dieses Posts auch in der Post-Zeile dupliziert.
Es geht also nicht darum, das Schemadesign zu ignorieren, sondern es eher auf die Eigenschaften von MongoDB abzustimmen. Wenn Sie das tun, werden Sie normalerweise feststellen, dass Sie natürlich ein gutes Schema entwerfen.
Als zusätzliche Referenz können Sie hier verweisen:http://docs.mongodb.org/ Handbuch/Kern/Datenmodellierung
