многие ко многим отношения с nosql (mongodb и Мангуст)

напротив, Решение 1 и 2-ваш лучший выбор. Решение 3 можно рассматривать, когда частота обновления/создания очень меньше по сравнению с частотой чтения проектов и пользователей, так как даже если для обновления/создания требуется два запроса, простота чтения будет компенсировать это.

чтобы выбрать решение 1 и 2, необходимо учитывать частоты считывания. Вам понадобятся проекты пользователя или использование проекта чаще и выбирайте в соответствии с этим. Если вы чувствуйте, что оба имеют относительно одинаковую частоту, лучше держать объект пользователя как можно менее кластеризованным. Какой бы вариант вы ни выбрали, подумайте о сохранении index на массиве, хранящем _ids (проектов или пользователей).

для ex.

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 значительно улучшить скорость ваших запросов на стороне, где вы боитесь, что будут значительные накладные расходы.

но держать index только если это отношение является важным отношением с большим количеством запросов. Если это просто особенность вашего проекта, вы можете сделать without индекс тоже.

если пользователь может делать много вещей и имеет много отношений, вам будет нужен этот объект пользователя постоянно в вашем приложении, поэтому, если ваше приложение не является конкретным проектом, было бы лучше не помещать идентификаторы проекта в схему пользователя. Но поскольку мы просто ставим идентификаторы, это не так много накладных расходов в любом случае. Нет об этом надо беспокоиться.

reg index на обоих массивах: Да, вы можете, конечно. Но когда вы идете на решение 3, вам вообще не нужен индекс, так как вы не будете делать запрос, чтобы получить список проектов пользователя или список пользователей в проекте. Решение 3 делает чтение очень легким, но написание немного громоздким. Но, как вы упомянули, ваш вариант использования включает reading>>writing, перейдите к решению 3, но всегда есть опасность несоответствия данных, о которой вам нужно позаботиться из.

индексирование просто делает вещи быстрее. Пройти через документы и немного погуглить. Ничего особенного. Запрос по индексированным массивам эффективнее, чем обычные массивы. Для экс. Предположим, вы используете решение 2. Сохраните идентификаторы проекта в поле 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.Предположим, у нас есть пользователь1. Чтобы получить проекты пользователя, мы делаем следующий запрос

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.

если вы размышляете над решением 1 против решения 2, Решение 1 Лучше, я думаю. Могут быть случаи, когда вам нужен пользователь без его проектов, но шансы потребовать проект без пользователей довольно низки. Но это зависит от вашего точного варианта использования.