Au contraire, les solutions 1 et 2 sont votre meilleur pari. La solution 3 peut être envisagée lorsque la fréquence de mise à jour/création est très inférieure à la fréquence de lecture des projets et des utilisateurs car même si pour mettre à jour/créer, cela nécessite deux requêtes, la facilité de lecture en sera compensée.
Pour choisir entre les solutions 1 et 2, il faut tenir compte des fréquences de lecture. Aurez-vous besoin des projets d'un utilisateur ou des utilisations d'un projet plus fréquemment et choisissez en fonction de cela. Si vous pensez que les deux ont relativement la même fréquence, il est préférable de garder l'objet utilisateur le moins groupé possible. Quelle que soit l'option que vous choisissez, pensez à conserver un index sur le tableau stockant le _id s (de projets ou d'utilisateurs).
Par ex.
userSchema = new Schema(
{//otherstuff
project_ids: [{type: Schema.Types.ObjectId, ref: 'Project'}})
...
})
userSchema.index({'project_ids':1})
ou
projectSchema = new Schema(
{//otherstuff
user_ids: [{type: Schema.Types.ObjectId, ref: 'User'}})
...
})
projectSchema.index({'user_ids':1})
Garder un index sur le tableau de _id améliorera considérablement la vitesse de vos requêtes du côté où vous craignez qu'il y ait une surcharge importante.
Mais gardez l'index seulement si cette relation est une relation importante avec beaucoup de requêtes en cours. S'il ne s'agit que d'une fonctionnalité secondaire de votre projet, vous pouvez vous en passer without un index aussi.
Si l'utilisateur peut faire beaucoup de choses et a beaucoup de relations, vous aurez constamment besoin de cet objet utilisateur tout au long de votre application, donc si votre application n'est pas spécifique au projet, il serait préférable de ne pas mettre les identifiants du projet dans le schéma utilisateur . Mais comme nous ne faisons que mettre les identifiants, ce n'est pas beaucoup de frais généraux de toute façon. Pas besoin de s'inquiéter pour ça.
Reg index sur les deux tableaux :Oui, vous pouvez bien sûr. Mais lorsque vous optez pour la solution 3, vous n'avez pas du tout besoin d'un index car vous n'effectuerez pas de requête pour obtenir la liste des projets d'un utilisateur ou la liste des utilisateurs d'un projet. La solution 3 rend la lecture très facile mais l'écriture un peu lourde. Mais comme vous l'avez mentionné, votre cas d'utilisation implique la reading>>writing , optez pour la solution 3, mais il existe toujours un risque d'incohérence des données dont vous devez vous occuper.
L'indexation rend les choses plus rapides. Parcourez les documents et faites un peu de recherche sur Google. Rien d'extraordinaire. L'interrogation sur des tableaux indexés est plus efficace que les tableaux normaux. Par ex. Supposons que vous utilisiez la solution 2. Stockez les identifiants de projet dans le champ project_ids.
Vous pouvez obtenir les projets d'un utilisateur facilement. C'est simple.
Mais pour obtenir des utilisateurs de project1. Vous avez besoin d'une requête comme celle-ci.
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.
De même pour la solution 1. Chaque projet a un champ user_ids. Supposons que nous ayons un user1. Pour obtenir les projets de l'utilisateur, nous effectuons la requête suivante
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.
Si vous réfléchissez à la solution 1 par rapport à la solution 2, la solution 1 est meilleure, je suppose. Il peut y avoir des cas où vous avez besoin d'un utilisateur sans ses projets, mais les chances d'exiger le projet sans utilisateurs sont assez faibles. Mais cela dépend de votre cas d'utilisation exact.
