Комментарии 9
Есть что-то подобное для Postgres?
Скорее всего, в реальном проекте этот код в миграциях/вызовах в прикладном коде просто не пройдет код-ревью, так как разбираться в нем и поддерживать его очень сложно и дорого, а автору предложат переписать, разбив на несколько запросов и перенеся часть логики в прикладной код.
Хотя, если ревьюер на SQL ничего сложнее
SELECT * FROM ... WHERE ... не писал, то проблемы у него возникнут, конечно.
С одной стороны, люто плюсую. Особенно в плане использования dblink.Такие вещи было бы удобней разруливать на клиентской стороне.
С другой стороны, если говорить про java, то большинство фреймворков миграции заточено на то, что миграция это набор sql скриптов. Это в какой-то мере может оправдать странную идею совать в sql то, что не очень-то туда лезет.
Порефлексировал на тему сложных миграций (таких, которые занимают несколько суток на проде) за несколько последних лет и понял, что для каждой из них придумывался свой индивидуальный подход. Почти ничего не переиспользовалось именно потому, что ситуации сильно разные.
То есть, нет никакой серебряной пули, но можно попробовать нарисовать диаграмму принятия решений, которая поможет понять, что вам нужно сделать. Как именно сделать - это уже детали и тут много факторов как раз про понятность, принятые в проекте практики...
Вот статью с такой диаграммой я бы почитал 😀
Для обновления или удаления миллионов записей в таблице БД под нагрузкой я сделал себе хранимую процедуру loop_execute(), спрятав все "сложности" внутри. Взял идеи из статьи и развил дальше. Модификация записей происходит пачками в отдельных транзакциях с контролируемым временем блокировки. Для удобства есть режим тестирования, отображение прогресса выполнения в процентах и приблизительного времени окончания работы! На многоядерных серверах распараллеливание в разы увеличивает скорость работы.
PostgreSQL Antipatterns: обновляем большую таблицу под нагрузкой