Создание объекта с помощью конструктора в сопоставлении объектов

Это зависит от того, что вы пытаетесь сделать.

В настоящее время вы настроили его как нормализованную базу данных, и это нормально, и то, как вы это делаете, уместно.

Однако есть и другие способы сделать это.

У вас может быть коллекция сообщений, в которой есть встроенные комментарии для каждого сообщения со ссылками на пользователей, которые вы можете итеративно запросить. Вы можете сохранить имя пользователя с комментариями, вы можете сохранить их все в одном документе.

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

С NoSQL, если вы согласитесь, что избыточность и пространство для хранения не являются проблемами из-за их стоимости (как в процессорное время, необходимое для обновления и затраты на жесткий диск для хранения дополнительных данных), денормализация не является проблемой (для встроенных массивов, которые становятся сотнями тысяч элементов, это может быть проблемой производительности, но большую часть времени это не проблема). Кроме того, у вас будет несколько серверов приложений и интерфейсов для каждого кластера баз данных. Попросите их сделать тяжелый подъем соединений и позволить серверам баз данных придерживаться чтения и записи.

TL; DR: То, что вы делаете, прекрасно, и есть другие способы сделать это. Ознакомьтесь с образцами моделей данных документации mongodb для некоторых замечательных примеров. http://docs.mongodb.org/manual/data-modeling/