Sie können entweder ein Schema entwerfen, in dem Sie Dokumente referenzieren oder einbetten können. Schauen wir uns die erste Option der eingebetteten Dokumente an. Mit Ihrer obigen Anwendung können Sie die Informationen wie folgt in einem Dokument speichern:
// db.table1 schema
{
"_id": 3, // table1_id
"is_active": true,
"created": ISODate("2015-04-07T16:00:30.798Z"),
"lang": [
{
"name": "foo",
"surname": "bar",
"address": "xxx"
},
{
"name": "abc",
"surname": "def",
"address": "xyz"
}
]
}
Im obigen Beispielschema hätten Sie im Wesentlichen table1_lang eingebettet Informationen in der Haupt-table1 dokumentieren. Dieses Design hat seine Vorzüge, einer davon ist die Datenlokalität. Da MongoDB Daten zusammenhängend auf der Festplatte speichert, stellt das Einfügen aller benötigten Daten in ein Dokument sicher, dass die sich drehenden Festplatten weniger Zeit benötigen, um nach einem bestimmten Ort auf der Festplatte zu suchen. Wenn Ihre Anwendung häufig auf table1 zugreift Informationen zusammen mit table1_lang Daten, dann werden Sie mit ziemlicher Sicherheit den eingebetteten Weg gehen wollen. Der andere Vorteil eingebetteter Dokumente ist die Unteilbarkeit und Isolation beim Schreiben von Daten. Nehmen wir zur Veranschaulichung an, Sie möchten ein Dokument entfernen, das einen Langschlüssel "name" mit dem Wert "foo" hat, dies kann mit einer einzigen (atomaren) Operation erfolgen:
db.table.remove({"lang.name": "foo"});
Weitere Einzelheiten zur Datenmodellierung in MongoDB finden Sie in den Dokumenten Einführung in die Datenmodellierung , insbesondere Modell 1:n-Beziehungen mit eingebetteten Dokumenten
Die andere Entwurfsoption ist das Referenzieren von Dokumenten, bei denen Sie einem normalisierten Schema folgen. Zum Beispiel:
// db.table1 schema
{
"_id": 3
"is_active": true
"created": ISODate("2015-04-07T16:00:30.798Z")
}
// db.table1_lang schema
/*
1
*/
{
"_id": 1,
"table1_id": 3,
"name": "foo",
"surname": "bar",
"address": "xxx"
}
/*
2
*/
{
"_id": 2,
"table1_id": 3,
"name": "abc",
"surname": "def",
"address": "xyz"
}
Der obige Ansatz bietet eine erhöhte Flexibilität beim Durchführen von Abfragen. Zum Beispiel, um alle untergeordneten table1_lang abzurufen Dokumente für die Hauptentität table1 mit id 3 ist unkompliziert, erstellen Sie einfach eine Abfrage für die Sammlung table1_lang :
db.table1_lang.find({"table1_id": 3});
Das obige normalisierte Schema mit Dokumentverweisansatz hat auch einen Vorteil, wenn Sie Eins-zu-Viele-Beziehungen mit sehr unvorhersehbarer Häufigkeit haben. Wenn Sie Hunderte oder Tausende von table_lang haben Dokumente pro geben table Entity hat das Einbetten so viele Rückschläge in Bezug auf räumliche Beschränkungen, denn je größer das Dokument ist, desto mehr RAM wird verwendet und MongoDB-Dokumente haben eine feste Größenbeschränkung von 16 MB.
Als allgemeine Faustregel gilt, dass ein eingebetteter Ansatz gut funktioniert, wenn das Abfragemuster Ihrer Anwendung bekannt ist und auf die Daten in der Regel nur auf eine Weise zugegriffen wird. Wenn Ihre Anwendung Daten auf viele Arten abfragt oder Sie die Datenabfragemuster nicht vorhersehen können, ist für diesen Fall ein stärker normalisiertes Dokumentreferenzierungsmodell geeignet.
Ref:
