@thefish, Тот кто это сказал, совершенно не понимает как работать с монгой. Там нет джойна, правда, потому что данные не нормализованы, но можно объявить таблицу как функцию и вызывать её, можно (нужно) использовать оператор агрегации $lookup, или DBRef.

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

@thefish,
хранить реляционные данные в нереляционной базе данныхебаный ты по голове

@thefish,
(нужно) использовать оператор агрегации $lookup
и потом фактически писать руками план запроса?

thanks, but no, thanks

@thefish, ну а ты хочешь лампово джойнить потенциально разные по структуре данные и пить смузи?

@belsnickel, youtube.com

@belsnickel, Я потенциально разные по структуре данные пакую в JSONB, индексирую если надо; а про монгу для хранения относительно важных данных года три как забыл (как про страшный сон).

А вот хипстеры на конференциях получают такие вот отповеди, как в /0

@thefish,
а про монгу для хранения относительно важных данных года три как забылСейчас (после 3.6) монга вполне устойчива, штабильна, и шардится/реплицируется как никто больше.
Хотя раньше тоже жить можно было.

@belsnickel,
шардится/реплицируется как никто больше
вот потому типичный юзкейс для монги — архив media-assets для партнеров, куда постфактум еще записываются всякие бизнес-показатели, типа CTR или времени экспозиции. Чтобы когда очередному менеджеру вздумается "А заебательский ролик у нас был в 2013 в черную пятницу, давайте повторим!" — не приходилось судорожно рыться в архивах почты в поисках видео для преролла.

т.е. быстро пухнущая файлопомойка со вспомогательными тегами, потенциально не влезающая на один сервер — для этого монго вполне ок. Для почти всего остального <strike>реляционная база</strike> postgres лучше.

@thefish,
. Для почти всего остального <strike>реляционная база</strike> postgres лучше.
Мой кейс начала года: бухгалтерский онлайн-продукт, однотенантный, потому что юзеров овер 90000 — каждому бд не выдашь. Зато каждый юзер хочет кастомные документы и отчёты со своими полями, которые он будет менять как ему вздумается.

Любая реляционная база сразу сосёт.

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

Если их можно представить в JSON, то я бы все равно взял постгрес + прикрутил в коде валидацию и генерацию UI через JSON Schema. Т.к. считаю что целостность для бухгалтерии must have, и реляционнная база справится с этим гораздо лучше.

Но это я.

@thefish,
т.е. по факту в базе хранились куски шаблонов для конечных пользователей? Нет. Таблица = документ.

Если их можно представить в JSON, то я бы все равно взял постгрес + прикрутил в коде валидацию и генерацию UI через JSON Schema. Т
Я к Бартунову и Космодемьянскому приставал с json'ом, ДАЖЕ ОНИ не рекомендовали так делать.

@belsnickel, сильно зависит от размера шаблона.
Если не влезает в 4кб, емнип, то да, придется чесать репу