если не поиграться, то формируйте требования, что с ними будет делаться, сколько их будет, размеры и т.п.

как получить массив какого либо поля для всех документов?

Цель просто разобраться в принципах монги

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

projection

Господа, такой нубский вопрос. Стоит ли и когда использовать рефсы ( связи между таблицами ) К примеру, у меня есть блог. Где есть Пост у которого есть поля mes, id. И есть коммент, у которого есть поле mes и post_id В доке монги сказано, что желательно хранить всё в одном документе. Т.е. в случае выше, мне стоило бы сделать у post массив comments куда пушить комменты? Соб-сно суть вопроса. Есть ли какой-либо пример по БД типа блог, где, на ваш взгялд, правильно использованы рефы в монге?

я как понял просто юзать .select()?

https://docs.mongodb.com/ecosystem/use-cases/storing-comments/

и привело к мысли, что я как-то не так юзаю инструмент

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

тогда можно пересесть на sql и радоваться жизни, пока достаточно производительности одного сервака и нет какихто мегатребований к доступности

На этой неделе я выкачу туда нормальный парсер запросов и добавлю FindAndModify и включу отображение explain. Из большого останется только добавить табы для коллекций и индексы, что я допилю на следующей. И что дальше? Какой инструмент вам нужен?

Расскажите!

версии в голове, надо записать. но я не придумал зачем нужны версии, если в 4.0 вобщем-то почти всё из 3.x работает :)

Привет. есть репликасет из трёх нод. к примеру нода3 сейчас мастер. потом происходит бадабум. хочется поднять одну ноду из трёх из бекапа (сделанной с помощью снапошота вирт.машины). и запустить её как примари. подняли ноду1, а она становится секондари и не хочет стать примари. с помощью cfg = rs.conf() cfg.members[0].priority = 1.5 cfg.members[1].priority = 1 cfg.members[2].priority = 1 rs.reconfig(cfg,{force: true}) поднял ей приоритет, но выборы почему-то не делают её примари, подскажите куда смотреть?

Подскажите, как $lookup работает? Например. Я делаю $lookup и вытаскиваю поле foreignCol.foo (а там есть индекс на foo) И потом после $lookup стадии, я сделаю $sort стадию и сортирую по foo Затем $limit, мне надо первую сотню. Так вот для этой первой сотни будет перелопачена вся коллекция foreignCol или будут взяты только первые сто документов (в порядке сортировки по foo) ?

Привет. есть репликасет из трёх нод. к примеру нода3 сейчас мастер. потом происходит бадабум. хочется поднять одну ноду из трёх из бекапа (сделанной с помощью снапошота вирт.машины). и запустить её как примари. подняли ноду1, а она становится секондари и не хочет стать примари. с помощью cfg = rs.conf() cfg.members[0].priority = 1.5 cfg.members[1].priority = 1 cfg.members[2].priority = 1 rs.reconfig(cfg,{force: true}) поднял ей приоритет, но выборы почему-то не делают её примари, подскажите куда смотреть?

new это опция findAndModify, которая говорит вернуть версию документа до или после обновления

$exists

но это работает только если у вас в запросе это единственное условие