Повторюсь, до чего же это классно: иметь в распоряжении нормальную реляционную базу данных. Не тридцать микросервисов с HTTP JSON API; не OpenSearch; не Монгу; не черт знает что еще.

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

Даже на Кложе это приличный быдлокод, который через пару месяцев хрен поймешь: map, map, filter, reduce, map, group-by – удачной отладки. В какой-нибудь Джаве с доменами и слоями проще выйти в окно.

А в SQL это запрос в 18 строчек. Функция json_path_query, которая собирает вложенные пути, один left join и пара условий. Все декларативно, нет переменных и циклов.

Еще один момент: если придет человек и спросит, почему эта штука посчиталась именно так, то с микросервисами я сосу лапу. Код отработал, и какие структуры были в памяти, догнать уже невозможно. Раньше я дампил состояние в S3, чтобы позже скачать его и воспроизвести расчеты. Но это долго! А теперь я выполнил запрос в PGAdmin, и человек такой: все верно, это у нас надо поправить.

Принцип простой: чтобы стало легче, нужно отстегнуть гири, которые сами же привязали. Если нет легкого, произвольного доступа к данным, ни о какой удобной работе нет речи.

← Зависание окон в Экселе

Зарплата до налогов →