@samatg а про VR будет вторая часть или ты даешь за деньги доступ к отредактированной части?

@samatg интересная ситуация про престу, хочется больше драмы в ввиде: потрачено 3млн, оценка $50 шаблон, $25 плагин для market place, кастомизация 30.000 в мес в течении 6 мес, тогда раскроется широта юмора анекдота.... глубина трагедии.. и моменты боевика появятся

Про cte и sql. А есть какие-то показательные примеры, кроме финансов и статистики, когда для бизнес-логики структурированное аггрегируемое хранилище (в противоположность key-value) вот прямо радикально улучшают что-то с технической точки зрения? Потому что пока кажется, что начиная с определённого масштаба (когда появляется шардинг, например) join становится дороже чем два запроса select from table1 limit x и select from table2 where id in (...)

Из системы А в систему Б идут события. Система Б дополняет события, и после появления некоторых событий делает выгрузку сущностей В в систему Д. Выгрузка делается из А. В ходе выгрузки есть цикл на 5 минут с попытками получить из системы А сущность именно с некоторыми данными. И если в течении года  минут данные не появляются, все выгружается как есть. А почему данные могут не появиться? Потому что система А состоит из кучи микросервисов с mongodb, и время распространения данных между ними непредсказуемо

Рано или поздно в key-value хранилище приходится решать задачи, давно уже решенные в реляционных БД. Только решать эти задачи будут не специалисты по computer science, а фронтендеры на полставки. Уж они вам нарешают.

норм причина у даунтайма дц в 2020

а lateral умеет? )

а что в IN? Хотя тут к обоим предложенным вариантам есть вопросы :)

посмотри сам по ссылке:)

Какого рода причины, например?

В in значения foreign key из table1

перечислением или сабселектом?

Это, кажется, называется straw man attack: придумать заведомо плохую систему A, приписать её негативные качества тому, что она использует MongoDB, и на этом основании декларировать, что key-value хранилища сосут проигрывают RDBMs. Не, не годится, try harder.

Я других-то не видел.

Два последовательных запроса: сначала получаем из базы сущности из таблицы 1, потом пробегаем по результату, формируем список id и делаем второй запрос к таблице b. То есть по сути работать с реляционной БД как с key-value.

Причинах чего именно? Вот нам надо обеспечить целостность данных. Как это делается в реляционных БД? Разными уровнями изоляции транзакций, которые защищают от разных ошибок. Как то же самое сделать в NoSQL? Только силами тех людей, которые пишут бизнес-логику, потому что других в типичной команде просто нет.

1) у тебя получается 2 сетевых взаимодействия вместо одного. причем в первый хоп ты можешь получить огромный список id, который
   - весь надо достать с диска в память базы
   - упаковать и отправить по сети
   - протащить по сети и положить в оперативку приложения
   - сформировать большой запрос
   - отправить его по сети в базу
   - протащить по сети, распаковать в оперативу базы
   - распарсить запрос
   - выбрать по айдишникам все записи из второй таблицы

2) конкретно в посгресе, если ты запихаешь в IN больше 100 значений, индексы применяться для этой операции не будут

Вот, хороший пример, спасибо. Проверка foreign key при вставке. Силами бизнес-логики, иначе негде.

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

Я утверждаю, что у писателей бизнес-логики ума не хватит сделать то же, что в РСУБД уже сделано, и сделать это столь же надёжно.

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