Здравствуйте, кто знает как можно искать одновременно по двум таблицам, которые между собой не связаны? (Например у меня есть таблица постов от двух разных типов пользователей, по таблице на каждый тип, и мне надо искать по допустим заголовку этих постов, но они по прежнему в отдельных таблицах)

2 запроса почему не устраивает?

А как мне с этого всего сделать общую пагинацию?

А не тянуло миллион объектов с базы

в чем ошибка?

причем тут монго?

не базы данных?

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

Нет

Здравствуйте, кто знает как можно искать одновременно по двум таблицам, которые между собой не связаны? (Например у меня есть таблица постов от двух разных типов пользователей, по таблице на каждый тип, и мне надо искать по допустим заголовку этих постов, но они по прежнему в отдельных таблицах)

Ребят у кого мак на м1 помогите плиз установить монгодб

А локально накатить никак?

А локально накатить никак?

Там одной командой он запускается )

В докере?

Да, за полностью локальный вариант я не знаю, даже не задумывался об этом при запуске. Мне опыта с локальным поднятием хватило и на винде

а что там? найти исполняемый файл, нажать ввод - это сложно?

А локально накатить никак?

Можно, есть официальныйпакет для homebrew https://www.mongodb.com/docs/manual/tutorial/install-mongodb-on-os-x/

Бывают различные сбои и софт криво ложится

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

тут логи не нужны, просто пароль был слит каким-то образом

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

на стандартную винду, 7-10-11 обычный установочник с офф сайта ложится как родной, какие сбои?

Это софт, автоматически такое делается

я немного удивлен, что по умолчанию mongo не включает авторизацию

если бы у меня на проде упала база из-за такого, сразу бы уволил того, кто причастен к "настройке"

если бы у меня на проде упала база из-за такого, сразу бы уволил того, кто причастен к "настройке"

Я знаю одного дурачка, который открыл базу на внешнем хосте, без пароля и никому не сказал, чтобы можно было к ней коннектиться через JetBrains ))

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

я этот вариант допускаю

Всем привет. Начинаю изучать mongo. Мне нужно запустить интерактивную оболочку mongo. Подскажите пожалуйста, правильную я директорию выбрал ?

Всем привет. Начинаю изучать mongo. Мне нужно запустить интерактивную оболочку mongo. Подскажите пожалуйста, правильную я директорию выбрал ?

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

А не проще было lint настроить и проверять автоматически?

В новой версии называется mongosh. Хз как для макоси ставится и может отдельно надо поставить

ставил отдельно через brew

Хм, добавил runValidators, но все равно ошибку при попытке обновить документ без required поля не получаю

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

Как строить отчеты при помощи aggregate? Вот такой вымышленный кейс: есть коллекция продукты - в ней название и кол-во и коллекция продажи. Хочу построить отчет по продажам. В простом варианте aggregate запросто решает задачу. Но есть три момента, которые все портят: (1) мы хотим включить в отчет продукты по которым не было продаж, (2) мы хотим посчитать долю продукта от общего объема продаж и (3) хотим посчитать долю по штукам относительно общего кол-ва, которое считается по коллекции продукты. Как это можно сделать?

Первым стейджем фасет с расчетами отдельными по продуктам и общие цифры. Следующим стейджем сведение результатов отдлельных фасетных выборок, то что итак будет делаться в коде

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

Ник, вот скажи новичку - если мы грузим такими запросами, как выше (сложными) БД, то производительность её снижается - значительно? или не значительно? представим пример, есть вот какая-то сложная операция, например О(n), сведение данных, агрегация и т.д. в 1 запросе. представим, что такая же логика, но описана кодом, на таком же уровне реализации (максимально оптимизировано, минимальное количество вызовов и т.д.) что эффективнее с точки зрения: 1. поддержки (о чём мы ранее общались, более сложные запросы сложнее поддерживать, изменять) 2. обработки (понятно, что если БД нагрузить, то она так же, как и нагруженное приложение будет долго обрабатывать данные) 3. потребления памяти (если приложение можно оптимизировать, то БД нет, кроме корневых конфигов) получается, что в итоге, обработка более сложных вещей в коде даёт из плюсов только "умение делать более сложные вещи" и "проще поддерживать и изменять написанное, в сравнении с запросами к БД" в твоей практике, как чаще бывает? конечно, есть вариант ответа на мой вопрос - всё зависит от конкретной ситуации, приложения, запросов, количества коннектов, но если усреднить реализацию кодом и БД

Ник, вот скажи новичку - если мы грузим такими запросами, как выше (сложными) БД, то производительность её снижается - значительно? или не значительно? представим пример, есть вот какая-то сложная операция, например О(n), сведение данных, агрегация и т.д. в 1 запросе. представим, что такая же логика, но описана кодом, на таком же уровне реализации (максимально оптимизировано, минимальное количество вызовов и т.д.) что эффективнее с точки зрения: 1. поддержки (о чём мы ранее общались, более сложные запросы сложнее поддерживать, изменять) 2. обработки (понятно, что если БД нагрузить, то она так же, как и нагруженное приложение будет долго обрабатывать данные) 3. потребления памяти (если приложение можно оптимизировать, то БД нет, кроме корневых конфигов) получается, что в итоге, обработка более сложных вещей в коде даёт из плюсов только "умение делать более сложные вещи" и "проще поддерживать и изменять написанное, в сравнении с запросами к БД" в твоей практике, как чаще бывает? конечно, есть вариант ответа на мой вопрос - всё зависит от конкретной ситуации, приложения, запросов, количества коннектов, но если усреднить реализацию кодом и БД

СУБД это всеголишь абстракция над самими данными и возможность выполнить логику над ними максимально близко к ним. Удобство написания запросов, языковая выразительность (как зависит размер текста запроса от сложности), ограничения связанные со способом хранения (документы, строки, колонки и т.п.), наличие сырцов или оперативной поддержки и т.д. все влияет на тот самый выбор инструмента, т.е. СУБД, под задачи. Так что если ваши хотелки в виде запросов делаются сложнее чем вам кажется должны были бы делаться, или запросы сильно дольше выполняются чем в других бд, то это лишь изза не профильного использования. И в таких случаях нормально и в коде реализовать необходимый функционал. По пунктам эффективности: 1. поддержка - увы но зависит от спецов и их уровня, если возможна ситуация с попаданием на проект человека со слабыми скилами, то монстрозапросы станут неприкасаемы, а функционал связанный с ними невозможно будет развивать без привлечения спецов или перепесывания 2. 3. как выше сказал СУБД позволяет работать максимально близко к данным достаточно эффективно, так что при возможности всегда надо гонять запросы в СУБД. Сам факт вычитки данных и передачи в код может не укладываться во временные и другие лимиты на выполнение запроса. Там где лимитов нет (например ежедневные отчеты) то это не имеет значения и хорошо уносится код.

понял, благодарю, да, тоже думал об IO проблемах

Ник, вот скажи новичку - если мы грузим такими запросами, как выше (сложными) БД, то производительность её снижается - значительно? или не значительно? представим пример, есть вот какая-то сложная операция, например О(n), сведение данных, агрегация и т.д. в 1 запросе. представим, что такая же логика, но описана кодом, на таком же уровне реализации (максимально оптимизировано, минимальное количество вызовов и т.д.) что эффективнее с точки зрения: 1. поддержки (о чём мы ранее общались, более сложные запросы сложнее поддерживать, изменять) 2. обработки (понятно, что если БД нагрузить, то она так же, как и нагруженное приложение будет долго обрабатывать данные) 3. потребления памяти (если приложение можно оптимизировать, то БД нет, кроме корневых конфигов) получается, что в итоге, обработка более сложных вещей в коде даёт из плюсов только "умение делать более сложные вещи" и "проще поддерживать и изменять написанное, в сравнении с запросами к БД" в твоей практике, как чаще бывает? конечно, есть вариант ответа на мой вопрос - всё зависит от конкретной ситуации, приложения, запросов, количества коннектов, но если усреднить реализацию кодом и БД

IO - это реально может быть большой проблемой. Сервера в Яндекс облаке вешаются очень легко именно на IO. ))

в моей практике было достаточно дешево выкидывать неоптимальные структуры и переналивать данные в нормальном виде или вообще уехать на другую БД. Но были и времена когда железо в наличии не было в состоянии переварить запросы определенного вида на вставке ввиду слабоватых дисков и все уносилось в код где строилась хитрая буферизация - по факту спец решение чтобы перелопать десяток ТБ из кафки не за месяц а в пределах недели