мерж норм

спасибо

https://play.db-ai.co/m/XcvafnFumAAB8J6u/edit?key=KXl9JmAFKX4 второая часть где merged делается то что вам нужно

да, я уже пробую на своей бд, понял в чем ошибка у меня была. Большое спасибо!

всем на работе вступить посоветую в группу )

https://play.db-ai.co/m/XcvafnFumAAB8J6u/edit?key=KXl9JmAFKX4

Зачем так сложно если $map есть

прост первое что выше предлагал

или ты про что

Я же уже ссылку дал. $reduce все-же для других задач немного. А просто трансформировать массив это классика для $map

https://play.db-ai.co/m/XcvafnFumAAB8J6u

не ту ссылкку кидал

Скажите, в монге есть возможность узнать когда была создан документ, если в нем нет поля `created_at` ?

точно нет. косвенно через _id

@dd_bb а есть способ сделать запрос с обох коллекций и склеить?

$lookup или $facet

У меня 2 коллекции с одинаковыми ID

зависит от того что вы хотите

точно нет. косвенно через _id

а какую фразу загуглить?

а какую фразу загуглить?

https://docs.mongodb.com/manual/reference/method/ObjectId.getTimestamp/#ObjectId.getTimestamp

зависит от того что вы хотите

Просто склеить данные с одним ID с обох коллекций

https://docs.mongodb.com/manual/reference/method/ObjectId.getTimestamp/#ObjectId.getTimestamp

хах, спасибо

а какую фразу загуглить?

objectid to date у аси было несколько раз

С игнором некоторых полей… (creationDate)

https://docs.mongodb.com/manual/reference/method/ObjectId.getTimestamp/#ObjectId.getTimestamp

это работает только к контексте mongo-shell

в контексте драйвера это работать не будет

https://jira.mongodb.org/browse/SERVER-9406

но эффективнее будет явно добаить created_at для новых документа, а в старых один раз вытащить из _id

Придумал. Буду тянуть стримом с обох коллекций, и кешировать елементы, если ID не совпадет.

😅

Просто склеить данные с одним ID с обох коллекций

$lookup

Он медленный

с чего вдруг

Будет бегать по всей коллекции, если не найдет

кто вам такое сказал

это просто вложенный запрос, у него ровно такой-же курсор как у обычной агрегации

Я проверял - долго работает и неудобно строит ответ

¯\_(ツ)_/¯

значит вы не точно объясняете свою задачу

Ну так вот он же на каждый елемент будет делать запрос, верно?

или вам нужен $facet

Ну так вот он же на каждый елемент будет делать запрос, верно?

да. а вам что надо?

У меня 2 разных коллекции. Но _id у документов одинаковые.

и?

вы ожидаемый результат опишите

не понятно какая ваша конечная цель

Если кодом - то я запрошу и там и там и попрошу отсортировать по _id, а вотом буду брать поелементно.

Давайте попробую с чистого листа.

какую задачу вы хотите решить?

на входе у вас есть две коллекции и они пересекаются каким-то идентификатором, это я уже понял

а что вы на выходе то хотите получить?

Collection articles: { "_id": 1, "title": "Foo baz" } { "_id": 2, "title": "Foo bar" } Collection images: { "_id": 1, "images": [ {"_id": UUID()}, {"_id": UUID()} ] } { "_id": 2, "images": [] }

А получить: { "_id": 1, "title": "Foo baz", "images": [ {"_id": UUID()}, {"_id": UUID()} ] } { "_id": 2, "title": "Foo bar", "images": [] }

это $lookup

Это lookup + unwind + group?

это просто $lookup

у вас какая-то странная денормализация

на входе у вас есть две коллекции, вы хотите одну пересечь с другой по общему идентификатору. это тот самый left join

а это $lookup

но если у вас images реально просто массив uuid, и их там не сотни килобайт и они вам постоянно нужны, то images проще положить в articles

но если у вас images реально просто массив uuid, и их там не сотни килобайт и они вам постоянно нужны, то images проще положить в articles

Это упрощенный пример.

Так получается "паразитное" поле с масивом images, как тогда правильно? db.getCollection('articles').aggregate([ { $lookup: { from: 'articleImages', localField: '_id', foreignField: '_id', as: 'images' } } ])

да

что такое «паразитное»?

симбиотное скорее тогда

документные хранилища позволяют вам тонко настроить степень денормализации. а это это трейдоф между «дорого записывать» в случае сильной денормализации и «дорого читать» в случае с 1 нормальной формой

что вам подходит никто кроме вас не знает

если у вас много записи и мало чтения, то нормальная форма вероятно будет дешевле, если у вас много чтения и мало записи, то денормализация вероятно будет выгоднее

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

Вот потому так…

что такое «паразитное»?

Масив images с одним найденным елементом (или и вовсе без)

В котором опять находятся images

если изменения редкие и вы всегда читаете и статьи и картинки то вам не нужна вторая коллекция

{ "_id": 1, "title": "Foo baz", "images" : [ { "_id" : 1, "images" : [ {UUID()}, {UUID()}] } ] }

да

но не вижу зачем ещё раз вложит images внутрь

если можно сразу просто images: [ UUID ] в корень

у вас и так _id сквозные

Часто нужны статьи без картинок. А все говорят документы в монге - чем меньше размером тем быстрее

не слушайте что говорят

Ну и еще (мелочь конечно) это разные компоненты в приложении.

документные хранилища позволяют вам тонко настроить степень денормализации. а это это трейдоф между «дорого записывать» в случае сильной денормализации и «дорого читать» в случае с 1 нормальной формой

^