Al contrario, le soluzioni 1 e 2 sono la soluzione migliore. La soluzione 3 può essere presa in considerazione quando la frequenza di aggiornamento/creazione è molto inferiore rispetto alla frequenza di lettura dei progetti e degli utenti, poiché anche se per aggiornare/creare sono necessarie due query, la facilità di lettura sarà compensata.
Per scegliere tra la soluzione 1 e 2, bisogna considerare le frequenze di lettura. Avrai bisogno di progetti di un utente o usi di un progetto più frequentemente e scegliere in base a quello. Se ritieni che entrambi abbiano relativamente la stessa frequenza, è meglio mantenere l'oggetto utente il meno raggruppato possibile. Qualunque opzione tu scelga, considera di mantenere un index sull'array che memorizza il _id s (di progetti o utenti).
Ad es.
userSchema = new Schema(
{//otherstuff
project_ids: [{type: Schema.Types.ObjectId, ref: 'Project'}})
...
})
userSchema.index({'project_ids':1})
o
projectSchema = new Schema(
{//otherstuff
user_ids: [{type: Schema.Types.ObjectId, ref: 'User'}})
...
})
projectSchema.index({'user_ids':1})
Mantenere un indice nell'array di _id migliorerà notevolmente la velocità delle tue query sul lato in cui temi che ci sarà un sovraccarico significativo.
Ma mantieni l'index solo se questa relazione è una relazione importante con molte query in corso. Se questa è solo una caratteristica secondaria del tuo progetto, puoi fare without anche un indice.
Se l'utente può fare molte cose e ha molte relazioni, avrai costantemente bisogno di quell'oggetto utente in tutta la tua app, quindi se la tua app non è specifica del progetto, sarebbe meglio non inserire gli ID del progetto nello schema utente . Ma dato che stiamo solo mettendo gli ID, non è comunque un sovraccarico. Non devi preoccuparti di questo.
Indice Reg su entrambi gli array:Sì, puoi ovviamente. Ma quando scegli la soluzione 3, non hai affatto bisogno di un indice poiché non eseguirai una query per ottenere l'elenco dei progetti di un utente o l'elenco degli utenti in un progetto. La soluzione 3 rende la lettura molto facile ma la scrittura un po' ingombrante. Ma come hai detto che il tuo caso d'uso prevede la reading>>writing , vai con la soluzione 3 ma c'è sempre il pericolo di incoerenza dei dati di cui devi occuparti.
L'indicizzazione rende le cose più veloci. Passa attraverso i documenti e fai un po' di googling. Nulla di bello. L'esecuzione di query su array indicizzati è efficiente rispetto agli array normali. Per es. Supponiamo che tu usi la soluzione 2.Memorizza gli ID del progetto nel campo project_ids.
Puoi ottenere facilmente i progetti di un utente. Questo è semplice.
Ma per ottenere utenti di project1. Hai bisogno di una query come questa.
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.
Analogamente per la soluzione 1. Ogni progetto ha un campo user_ids. Assumiamo di avere un utente 1. Per ottenere i progetti dell'utente eseguiamo la query seguente
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.
Se stai riflettendo sulla soluzione 1 rispetto alla soluzione 2, la soluzione 1 è migliore, immagino. Potrebbero esserci casi in cui hai bisogno di un utente senza i suoi progetti, ma le possibilità di richiedere il progetto senza utenti sono piuttosto basse. Ma dipende dal tuo caso d'uso esatto.
