Если комментариев к статье неограниченное количество, то хранить данные таким образом - неудачная идея. В mongodb документ по умолчанию не может превышать более 16 mb, но даже при отсутствии подобного ограничения, это привело бы к единовременному считыванию большого объема данных в память. В таком случае данные следует моделировать также, как и в РСУБД.
Есть
CAP-теорема и выбирать тип базы данных нужно исходя из того, какие 2 из 3 свойств для вас важнее. РСУБД дают согласованность и доступность (CA), но жертвуют возможностью разделения такой базы, nosql решения идут другим путем и жертвуют согласованностью в пользу доступности и устойчивости к разделению (AP). Согласованность данных в таких системах достигается при помощи шаблона
Saga вместо ACID.
В целом NoSQL это про проекты данные которых не помещаются в рамках одного сервера, а не про то, каким образом моделировать эти данные. Вложенные документы в mongodb - это скорее следствие её архитектуры, которое используют как маркетинговый ход, чем решение, которое будет использоваться повсеместно. В подавляющем большинстве случаев документы будут ссылаться друг на друга, точно также как это происходит и в РСУБД.
Для проекта с крохотными объемами данных логичнее выбирать РСУБД и тем самым значительно упростить себе жизнь. Но в целом как используют NoSQL, шардируют данные и как достигают согласованности данных при отсутствии ACID знать желательно, хотя бы в общих чертах.
Самое ужасное, это выбрать базу данных и использовать её неправильно, как пример документа с вложенными комментариями при условии их бесконечности в mongodb. Пишем скрипт генерирующий триллион комментариев к статье, а затем просим нам выдать эту статью и сайт уходит в офф. Хорошо что в mongodb есть защита от дурака.
Средний
