Эти данные элементарно могут разъехаться, если второй запрос не выполнится

так разве неделают ? как считать сколько у автора постов всего ?

Количество постов хранить гораздо проще цифрой. Массив ради количества хранить как-то странно

Эти данные элементарно могут разъехаться, если второй запрос не выполнится

но точно также если я буду увеличивать счетчик постов у автора, и возникнит ошибка, данные также разъедутся

но точно также если я буду увеличивать счетчик постов у автора, и возникнит ошибка, данные также разъедутся

Можно пересчитывать на каждую вставку нового поста или в фоне. Если счётчик уедет на 1-2 значения, никто не умрёт - это просто кеш для ускорения доступа к числу постов. А вот неконсистентные связи могут много крови попортить.

Тем более, что достать число и посчитать длину массива - это немного разные по стоимости операции.

Тем более, что достать число и посчитать длину массива - это немного разные по стоимости операции.

может глупость напишу, но я использовал aggregate() и использовал этот массив чтобы создать поле posts_count и другие счетчики ....да там есть еще два массива для лайков , подписчиков и тд )) значит это все не правильно ? блин

или вот как мне узнать список постов какие лайкнул пользователь не создавая у него массив с id шниками постов ?

Все зависит от того как данные будут потом использоваться. Показать список пользователей с количеством их постов - довольно частый кейс. Показать список пользователей со списком постов, которые они полайкали... С учётом того, что лаков могут быть сотни, это вряд ли понадобится

для этого можно популировать или не популировать данные постов, а чтобы не возвращать массив когда не надо я и хотел использовать aggregate(). в общем придется думать. над этим

Aggregate медленный. Aggregate с lookup - ещё медленнее.

Лучше хранить данные в таком виде, в котором их потом будет удобно доставать

Но основная проблема так и не решена. При сохранение поста мне придет искать автора отдельно, если я не могу пропопулировать его данные в пост. потому что пост должен содержать в себе данные автора.

Если, конечно, соотношение записи к чтению не в пользу записи. Но так редко бывает.

Ну вообще, findOneAndUpdate возвращает документ Я не знаю что такое findById..., это явно что-то из обвязки фреймворка

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

Что-то голова не соображает. Как написать аналогично вот такому SQL SELECT message.*, user.* FROM message, user WHERE message.author_id = user.user_id AND (user.user_id = ? OR user.user_id IN (SELECT whom_id FROM follower WHERE who_id = ?)) ORDER BY message.pub_date DESC LIMIT ?

Картинкой

никак

есть $lookup

в его сторону смотри

но вообще если нужно делать такие вещи в NoSQL, значит данные структурированы неправильно

Ах. То-то я думаю голова взрывается от попытки сообразить.

noSQL все больше и больше нравится, но пока стоооолько времени потратил на все это…

Кажется простая задача. Получить "message" с добавленным в него полем email из колекции users где message.author_id == user._id

Ой. Я всего местами localField и foreignField перепутал 🙃

но вообще если нужно делать такие вещи в NoSQL, значит данные структурированы неправильно

Такие вещи это какие?

Такие вещи это какие?

Я думаю он про связывающую таблицу follower. Которая many to many

Такие вещи это какие?

джоины

Я еще новичок в mongodb но если я хочу вытащить скажем пользователя и его посты надо два запроса делать?

Во. Я как раз этим занимаюсь)

Я еще новичок в mongodb но если я хочу вытащить скажем пользователя и его посты надо два запроса делать?

курсы чтоли проходите?

У меня 2 колекции: 'messages': в которой 'author_id' "ссылается" на документ из 'users' колекции.

Пока не получается, не могу понять почему. Либо все users вынимаются и ложатся в каждый документ messages либо пусто

messages = mongo.db.messages.aggregate([ { '$lookup': { 'from': 'users', 'localField': 'author_id', 'foreignField': '_id', 'as': "email" } } ])

курсы чтоли проходите?

делаю проект и структуру сделал как в реляционных бд и тут наткнулся на этот пост

но вообще если нужно делать такие вещи в NoSQL, значит данные структурированы неправильно

этот

ну вот самый простой пример из доки как в монге решаются такие проблемы

https://docs.mongodb.com/manual/tutorial/model-embedded-one-to-many-relationships-between-documents/

https://docs.mongodb.com/manual/applications/data-models/

https://www.mongodb.com/blog/post/thinking-documents-part-1?jmp=docs&_ga=2.155086200.1944121697.1511842606-657691548.1462567944

Мне не удобно изменять структуру больше. Если переместить message в user, то в будущем когда мне нужно будет вывести все сообщения от пользователей с которыми я дуржу разве не будет еще ужасней?

в таком случае действительно лучше сделать 2 коллекции, хранить референсы на всех твоих друзей

Ну я вот сделал 2 колекции. Соощения отдельно. Пользователи отдельно. У пользователя есть масив "друзья" с id-шками на других пользователей

Думаю потом брать этот масив и искать по сообщениям

да, так будет проще

Кажется простая задача. Получить "message" с добавленным в него полем email из колекции users где message.author_id == user._id

а вот это лучше не делать, если тебе нужен email то денормализовать скорее всего выгоднее

$lookup медленный

Эм. А как тогда сделать. Всеравно же прийдеся запрашивать с пользователя емейл

Блин. На первом же запросе застрял. А обещал что за день все SQL-> noSQL >_<

Я понял чего не работает. Я то сверяю по _id, а он в первой колекции как String

Эм. А как тогда сделать. Всеравно же прийдеся запрашивать с пользователя емейл

ну у тебя сообщения как приходят в приложение? денормализовать в том плане чтобы продублировать email поле в messages коллекции при вставке, а не из users его джоинить, если это часто требуется

А если user сменить свой email?

Пробегать по всем messages? Ьам тх мнооого будет(

да, не очень но мне сложно что-то сказать, я даже не знаю что за приложение и как оно должно себя вести

монга лучше всего подходит когда данные можно представить в виде дерева

делаю проект и структуру сделал как в реляционных бд и тут наткнулся на этот пост

Тут главная ошибка - если данные реляционные и их структура реляционная, то лучше использовать реляционную базу иначе будет много боли.

Тут главная ошибка - если данные реляционные и их структура реляционная, то лучше использовать реляционную базу иначе будет много боли.

Боль? Нет, не слышал… — https://bpaste.net/show/e62c8a27b885

aggregate, lookup 😭

Когда в базе будет несколько сотен тысяч сообщений - этот запрос умрёт

А что делать? 😞

Ну во-первых выносить sort и limit в самое начало pipeline

Разумно! Согласен!

Если лимит будет мелким, то lookup же тогда не страшен?

Конкретно в этом случае - скорее всего два простых запроса будут легче и быстрее, чем aggregation.

Проблемы начинаются когда надо достать сразу N постов у N пользователей

Это же еще не все)

Там в match еще предстоит добавить $or: [{...}, {$in: }]

Запрос уже в экране не умещается)

Зато sql учить не надо :)

Зато sql учить не надо :)

Монга конечно прекрасна :) Но лучше уж sql чем aggregate :)

aggregate на самом деле норм, но не в моем случае)

Когда не умеешь готовить данные в noSQL — https://bpaste.net/show/232d411da8c5

А можно вот эти $project обединить? {'$project': {'author.pw_hash': 0}}, {'$project': { 'author': { '$arrayElemAt': ['$author', 0] }, 'text': 1, 'pub_date': 1 }}

А ты пробовал их объединить?

А возможно ли модифицировать документ в capped collection ?

у меня ответ на этот вопрос занял примерно время на окрытие гугла и ввода запроса

что тебе помешало также сделать?

в гугл информация возможно устарела