Im Gegenteil, Lösung 1 und 2 sind Ihre beste Wahl. Lösung 3 kann in Betracht gezogen werden, wenn die Aktualisierungs-/Erstellungshäufigkeit im Vergleich zur Lesehäufigkeit von Projekten und Benutzern sehr gering ist, denn obwohl zum Aktualisieren/Erstellen zwei Abfragen erforderlich sind, wird die einfache Lesbarkeit dies wettmachen.
Um zwischen Lösung 1 und 2 zu wählen, müssen Sie die Lesefrequenzen berücksichtigen. Benötigen Sie häufiger Projekte eines Benutzers oder Verwendungen eines Projekts und wählen Sie danach aus. Wenn Sie das Gefühl haben, dass beide relativ gleich häufig sind, ist es besser, das Benutzerobjekt so wenig gruppiert wie möglich zu halten. Welche Option Sie auch wählen, ziehen Sie in Betracht, einen index zu führen auf dem Array, das die _id speichert s (von Projekten oder Benutzern).
Zum Beispiel.
userSchema = new Schema(
{//otherstuff
project_ids: [{type: Schema.Types.ObjectId, ref: 'Project'}})
...
})
userSchema.index({'project_ids':1})
oder
projectSchema = new Schema(
{//otherstuff
user_ids: [{type: Schema.Types.ObjectId, ref: 'User'}})
...
})
projectSchema.index({'user_ids':1})
Einen Index auf dem Array von _id beibehalten wird die Geschwindigkeit Ihrer Abfragen auf der Seite erheblich verbessern, auf der Sie einen erheblichen Overhead befürchten.
Behalten Sie aber den index bei nur wenn es sich um eine wichtige Beziehung mit vielen Abfragen handelt. Wenn dies nur ein Nebenfeature Ihres Projekts ist, können Sie without auskommen auch ein Index.
Wenn der Benutzer viele Dinge tun kann und viele Beziehungen hat, benötigen Sie dieses Benutzerobjekt ständig in Ihrer App. Wenn Ihre App also nicht projektspezifisch ist, wäre es besser, die Projekt-IDs nicht in das Benutzerschema aufzunehmen . Aber da wir nur die IDs setzen, ist es sowieso kein großer Overhead. Darüber brauchen Sie sich keine Sorgen zu machen.
Reg-Index auf beiden Arrays:Ja, das können Sie natürlich. Wenn Sie sich jedoch für Lösung 3 entscheiden, benötigen Sie überhaupt keinen Index, da Sie keine Abfrage durchführen, um die Liste der Projekte eines Benutzers oder die Liste der Benutzer in einem Projekt abzurufen. Lösung 3 macht das Lesen sehr einfach, aber das Schreiben etwas umständlich. Aber wie Sie bereits erwähnt haben, beinhaltet Ihr Anwendungsfall das reading>>writing , wählen Sie Lösung 3, aber es besteht immer die Gefahr von Dateninkonsistenzen, um die Sie sich kümmern müssen.
Die Indizierung macht die Dinge nur schneller. Gehen Sie die Dokumentation durch und googeln Sie ein wenig. Nichts Besonderes. Das Abfragen von indizierten Arrays ist effizienter als normale Arrays. Zum Bsp. Nehmen wir an, Sie verwenden Lösung 2. Speichern Sie die Projekt-IDs im Feld project_ids.
Sie können die Projekte eines Benutzers einfach abrufen. Das ist einfach.
Aber um Benutzer von project1. Sie müssen eine Abfrage wie diese ausführen.
User.find({project_ids:project._id},function(err,docs){
//here docs will be the list of the users of project1
})
//The above query might be slow if the user base is large.
//But it can be improved vastly by indexing the project_ids field in the User schema.
Ähnlich für Lösung 1. Jedes Projekt hat das Feld user_ids. Nehmen wir an, wir haben einen Benutzer1. Um die Projekte des Benutzers zu erhalten, führen wir die folgende Abfrage durch
Project.find({user_ids:user1._id},function(err,docs){
//here docs will be the projects of user1
//But it can be improved vastly by indexing the user_ids field in the Project schema.
Wenn Sie über Lösung 1 im Vergleich zu Lösung 2 nachdenken, ist Lösung 1 meiner Meinung nach besser. Es kann Fälle geben, in denen Sie Benutzer ohne seine Projekte benötigen, aber die Wahrscheinlichkeit, dass das Projekt ohne Benutzer benötigt wird, ist ziemlich gering. Aber es hängt von Ihrem genauen Anwendungsfall ab.
