Das Problem ist, dass Sie Ihre Daten übernormalisieren. Ein Auftrag wird von einem Kunden definiert, der zum gegebenen Zeitpunkt an einem bestimmten Ort wohnt, einen bestimmten zum Zeitpunkt des Auftrags gültigen Preis zahlt (der sich über die Nutzungsdauer stark ändern kann und den Sie ohnehin dokumentieren müssen und mehrere andere Parameter die alle nur zu einem bestimmten Zeitpunkt gültig sind . Also zum Dokumentieren eine Bestellung (Wortspiel beabsichtigt), müssen Sie alle Daten für diesen bestimmten Zeitpunkt beibehalten. Lassen Sie mich Ihnen ein Beispiel geben:
{ _id: "order123456789",
date: ISODate("2014-08-01T16:25:00.141Z"),
customer: ObjectId("53fb38f0040980c9960ee270"),
items:[ ObjectId("53fb3940040980c9960ee271"),
ObjectId("53fb3940040980c9960ee272"),
ObjectId("53fb3940040980c9960ee273")
],
Total:400
}
Solange sich weder der Kunde noch die Details der Artikel ändern, können Sie jetzt nachvollziehen, wohin diese Bestellung gesendet wurde, welche Preise auf der Bestellung waren und dergleichen. Aber was passiert nun, wenn der Kunde seine Adresse ändert? Oder wenn sich der Preis eines Artikels ändert? Sie müssten diese Änderungen in ihren jeweiligen Dokumenten nachverfolgen. Es wäre viel einfacher und ausreichend effizient, um die Bestellung wie folgt zu speichern:
{
_id: "order987654321",
date: ISODate("2014-08-01T16:25:00.141Z"),
customer: {
userID: ObjectId("53fb3940040980c9960ee283"),
recipientName: "Foo Bar"
address: {
street: "742 Evergreen Terrace",
city: "Springfield",
state: null
}
},
items: [
{count:1, productId:ObjectId("53fb3940040980c9960ee300"), price: 42.00 },
{count:3, productId:ObjectId("53fb3940040980c9960ee301"), price: 0.99},
{count:5, productId:ObjectId("53fb3940040980c9960ee302"), price: 199.00}
]
}
Mit diesem Datenmodell und der Verwendung von Aggregationspipelines haben Sie mehrere Vorteile:
- Preise und Adressen oder Namensänderungen oder Geschenkkäufe eines Kunden müssen Sie nicht mehr selbstständig nachverfolgen – es ist bereits dokumentiert.
- Mit Aggregationspipelines können Sie Preistrends erstellen, ohne Preisdaten unabhängig speichern zu müssen. Sie speichern einfach den aktuellen Preis eines Artikels in einem Bestelldokument.
- Sogar komplexe Aggregationen wie Preiselastizität, Umsatz nach Staat/Stadt und dergleichen können mit ziemlich einfachen Aggregationen durchgeführt werden.
Im Allgemeinen kann man mit Sicherheit sagen, dass in einer dokumentenorientierten Datenbank jede Eigenschaft oder jedes Feld, das einer zukünftigen Änderung unterliegt und diese Änderung eine andere semantische Bedeutung erzeugen würde, innerhalb des Dokuments gespeichert werden sollte. Alles, was sich in Zukunft ändern kann, aber die semantische Bedeutung nicht berührt (im Beispiel das Benutzerpasswort), kann über eine GUID verknüpft werden.
