Спасибо за ваш комментарий. Дело не только в заботе о миграциях но и вообще в эксплуатации и анализе. Хранимые функции и процедуры в целом оптимизировать тяжелее десятка прямых SQL запросов где бизнес логика снаружи. Внешне простой текст запроса вроде call prc(1034, '2024-01-01 00:00.00') где внутри много вложенной логики может вылиться в трассировочный файл в несколько гигабайт. Выделить проблемный фрагмент кода сразу не так просто. (Трассировка возможна и в PostgreSQL. Но это выглядит иначе чем в Оракле. Tkprof нет. Хотя в форках Postgres такие реализации уже встречаются.)
Смотря что это за процедуры, какую специфику Оракл они используют. Каким образом они были сгенерированы или написаны. В целом это больше вопрос к архитекторам и разработчикам системы без связки с которыми и без понимания специфики работы компонентов, тестирования, действуя только силами DBA - миграция действительно дело часто безнадежное... Даже переписав процедуры синтаксически эквивалентно - не факт что это будет работать.
В результате этих работ с архитекторами должна быть готова в PostgreSQL рабочая схема БД. С какой то вероятностью у них она уже может быть готова. Даже в Оракловом RCU (repository creation utility) для хранения метаданных продукта в списке - довольно большой набор СУБД от MySQL до Oracle, как я помню был и PostgreSQL. Раньше обычно по умолчании выбирали только Оракл, хотя есть возможности и выбрать другую СУБД. Пресоздав таким образом структуру под другую БД и корректно мигрировав данные вы можете охватить целый пласт продуктов. В общем, все может быть и не настолько плохо как может показаться изначально. И вопрос нужно внимательно изучить.
Конечно здесь лучше определить целесообразность, что именно лучше в конкретном случае. Могут уйти месяцы на пеписывание кода хранимок. Но это все делается, в неторопливой творческой обстановке, без необходимости вмешательства в исходную систему, и ее остановке. Главное в итоге чтобы к часу Х когда происходит сама миграция системы DDL целевой PostgreSQL была готова уже развернута. И в итоге нам нужно только быстро и консистентно перенести данные. Миграция в большинстве происходит с простоем, он как раз и наиболее критичен. И чем быстрее перенесем данные - тем лучше. Хорошо если управляемся в техокно 1-3 часа. Может быть разрешенный простой 10-20 часов, если например вектора изменений накапливаются уровнем выше на Кафке. Затем они перенаправляются на новый источник. Но например когда данные переносят 3(!) недели - это может оказаться недопустимым. Вот на это мы и хотели здесь обратить внимание.
В последнее время все же страются выносить всю бизнес-логику из БД на уровень прикладного ПО. БД является только хранилищем данных. В этом случае конечно все проще.
Справедливое замечание. Сейчас рекомендуют все же использовать GENERATED BY/AS... с вариациями. Но в данном случае важно было передать смысл.
Спасибо за ваш комментарий. Дело не только в заботе о миграциях но и вообще в эксплуатации и анализе. Хранимые функции и процедуры в целом оптимизировать тяжелее десятка прямых SQL запросов где бизнес логика снаружи. Внешне простой текст запроса вроде call prc(1034, '2024-01-01 00:00.00') где внутри много вложенной логики может вылиться в трассировочный файл в несколько гигабайт. Выделить проблемный фрагмент кода сразу не так просто. (Трассировка возможна и в PostgreSQL. Но это выглядит иначе чем в Оракле. Tkprof нет. Хотя в форках Postgres такие реализации уже встречаются.)
Смотря что это за процедуры, какую специфику Оракл они используют. Каким образом они были сгенерированы или написаны. В целом это больше вопрос к архитекторам и разработчикам системы без связки с которыми и без понимания специфики работы компонентов, тестирования, действуя только силами DBA - миграция действительно дело часто безнадежное... Даже переписав процедуры синтаксически эквивалентно - не факт что это будет работать.
В результате этих работ с архитекторами должна быть готова в PostgreSQL рабочая схема БД. С какой то вероятностью у них она уже может быть готова. Даже в Оракловом RCU (repository creation utility) для хранения метаданных продукта в списке - довольно большой набор СУБД от MySQL до Oracle, как я помню был и PostgreSQL. Раньше обычно по умолчании выбирали только Оракл, хотя есть возможности и выбрать другую СУБД. Пресоздав таким образом структуру под другую БД и корректно мигрировав данные вы можете охватить целый пласт продуктов. В общем, все может быть и не настолько плохо как может показаться изначально. И вопрос нужно внимательно изучить.
Конечно здесь лучше определить целесообразность, что именно лучше в конкретном случае. Могут уйти месяцы на пеписывание кода хранимок. Но это все делается, в неторопливой творческой обстановке, без необходимости вмешательства в исходную систему, и ее остановке. Главное в итоге чтобы к часу Х когда происходит сама миграция системы DDL целевой PostgreSQL была готова уже развернута. И в итоге нам нужно только быстро и консистентно перенести данные. Миграция в большинстве происходит с простоем, он как раз и наиболее критичен. И чем быстрее перенесем данные - тем лучше. Хорошо если управляемся в техокно 1-3 часа. Может быть разрешенный простой 10-20 часов, если например вектора изменений накапливаются уровнем выше на Кафке. Затем они перенаправляются на новый источник. Но например когда данные переносят 3(!) недели - это может оказаться недопустимым. Вот на это мы и хотели здесь обратить внимание.
В последнее время все же страются выносить всю бизнес-логику из БД на уровень прикладного ПО. БД является только хранилищем данных. В этом случае конечно все проще.