Middle-ware и бизнес-логика на SQL

Как называется эффект (явление)

Это жопа, господа. Но таки у нас тоже это имеет место быть.

Какие методы постепенного рефакторинга таких систем существуют?

Вытаскивай потихоньку всё оттуда куда-нибудь. Какие еще тут методы.

А есть уверенность, что это решит проблему?

У сироткина был пост на эту тему, где он хранимки выпиливал: https://yakov-sirotkin.livejournal.com/296454.html

Еще один момент - не совсем понятно почему сервер загибается. Логика уходит туда где хранятся данные, максимально близко к ним. Почему это стало узким местом архитектуры ТС поленился написать.

У меня был продакшен на постгресе, как раз с хранимками/триггерами/вьюхами, тормоза были только если делали явную глупость.

Я тоже сталкиваюсь с такой практикой и мне не понятно, почему это плохо? Единственное умозрительное исключение - наличие orm в архитектуре ПО - тут да, хранимки становятся адовым костылём.

Базы данных не нужны!

Единственное умозрительное исключение - наличие orm в архитектуре ПО

ОРМ создан для тех, кто ничего серьезнее «бложика» не создавал

На практике, это вызывает дикие тормоза на 10-ядерном Xeon + 128 GB RAM.

Что-то у вас не так, обычно логика на SQL глючит, падает после «только добавил новую фичу», непонятная но не тормозит. А у вас, похоже такие мастера, что единственное достоинство этого подхода продолбали.

Что-то у вас не так

Индексов во многих таблицах не хватает.

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

Хранимок там мало. В основном, все вычисления SQL-запросами, которые вызываются из Java-бэкенда.

Есть процедура, которая добавляет 60 тыс записей в таблицу (20 полей) в течение 3,5 часов. Надо две-три недели, чтобы оптимизирвать эту вставку +построение индексов, пока не найду в себе моральные силы, сделал пока на 30%.

Кстати да. Если там всё нормально, то со всякими orm быстрее работать точно не будет, т.к. это - еще одна прослойка. Логика вытаскивается в отдельный слой не ради скорости.

Индексов во многих таблицах не хватает.

Кстати, такая же проблема была 10 лет назад в другой гос.организации, куда по пилотному проекту внедрялась АИС «Кадастр». Оборудования и софта было закуплено для нашего региона на 2 млрд.рублей.

А софтовая обвязка - переписана какими-то питерскими студентами, и до сих пор является глючной. Часть этой обвязки - «Публичная кадастровая карта».

А, ну так это простые говнокодеры.

Методы борьбы с ними - послать нафиг, самый эффективный. Потому как ты если навесишь индексы, то это до первого обновления, потом придёт васян-апдейтер и всё поломает.

Как называется эффект (явление)

«Мой первый энтерпрайс-проЭкт».

Какие методы постепенного рефакторинга таких систем существуют?

Указать в ТЗ, чтобы в качестве базы использовался elasticsearch.

На практике, это вызывает дикие тормоза на 10-ядерном Xeon + 128 GB RAM.

серверный sql код, это хранимки чтоли? открою тайну, если не следить за индексами, то и не «серверный код» будет тормозить точно так же.

серверный sql код, это хранимки чтоли?

В основном, большие JOINы.

эм, а в чем проблема больших join'ов? :) тем что программизд не умеет индексы создавать?

или ты думаешь что выбрать 10 таблиц полностью и заджойнить их «вручную» средствами языка будет быстрее?

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

Нет. Я даже скажу, что на базе с хранимых процедурами на большом проекте имеет смысл даже хотя бы свой орм накостылить.

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

На практике, это вызывает дикие тормоза на 10-ядерном Xeon + 128 GB RAM.

какая субд? (вендор). может еще так навскидку - оценка размеров бд, суммарный объем таблиц, индексов, одновременно работающих коннектов к базе

А что страшного в больших джойнах? Даже без индексов все должно быть вполне себе быстро, если база нормализована, джойним по числовым значениям и тащим только нужные поля таблиц.