与nosql(mongodb和mongoose)有很多关系

要在解决方案1和2之间进行选择,您需要考虑读取频率.您是否需要更频繁地使用用户的项目或使用项目,并根据需要进行选择.如果您觉得两者频率相对相同,则最好将用户对象尽可能少地聚集在一起.无论您选择什么选项,请考虑在存储_ids(项目或用户)的数组中保留索引.

例如

userSchema = new Schema(
            {//otherstuff
               project_ids: [{type: Schema.Types.ObjectId,ref: 'Project'}})
              ...
            }) 
userSchema.index({'project_ids':1})

要么

projectSchema = new Schema(
            {//otherstuff
               user_ids: [{type: Schema.Types.ObjectId,ref: 'User'}})
              ...
            }) 
projectSchema.index({'user_ids':1})

在_id数组上保持索引会大大提高您的查询速度,您可能会担心这会导致重大开销.

但是只有当这个关系与许多查询的重要关系时才保持索引.如果这只是您的项目的一个侧面功能,您也可以没有索引.

如果用户可以做很多事情并且有很多关系,那么您将在整个应用程序中不断地需要该用户对象,所以如果您的应用程序不是项目特定的,那么最好不要将项目ID放在用户模式中.但是,正如我们只是把ids,它不是太多的架空.没必要担心.

两个数组的Reg索引：是的,你可以.但是当你去解决方案3时,你根本不需要一个索引,因为你不会做一个查询来获取一个用户的项目列表或一个项目中的用户列表.解决方案3使阅读变得非常容易,但写得有点麻烦.但是正如你所提到的,你的用例涉及阅读>>写作,请使用解决方案3,但总是有数据不一致的危险,您需要照顾.

索引只是使事情更快.通过the docs,做一些谷歌搜索.没什么好想的查询索引数组比正常数组有效.例如让我们假设你使用解决方案2.
将项目ID存储在project_ids字段中.

您可以轻松地获得用户的项目.这是直接的.

但是要得到project1的用户.你需要这样的查询.

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.

Similary解决方案1.每个项目都有user_ids字段.让我们假设我们有一个user1.
为了获得用户的项目,我们做下面的查询

Project.find({user_ids:user1._id},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.

如果您正在思考解决方案1与解决方案2,解决方案1更好我猜.在没有他的项目的情况下,您可能需要用户,但没有用户需要项目的机会相当低.但这取决于你的确切用例.