К сожалению, не всё можно быстро доработать — между ядрами баз есть коренные отличия, которые в конечном счёте влияют на то, как мы пишем код. Приведу простой пример: допустим, у вас есть хранимая функция, которая делает какой-нибудь сложный расчёт в течение, скажем, часа, при этом активно обновляет данные во временной таблице. Такой код будет нормально работать на Oracle, но если его перенести на PostgreSQL, расчёт может не завершиться никогда — из-за bloating. В результате придётся переписывать код под базу.
Или другой пример: допустим, архитектура системы построена на длинных транзакциях, и в коде активно используются конструкции вида begin -- что-то пишем в базу exception end. При переходе на Postgres получим проблемы с LWLock, а возможно, и со счётчиком транзакций. И опять же, нужно будет править код функций.
В общем, для того чтобы быстро показать импортозамещение — вариант очень хороший. А вот для реальной работы под нагрузкой всё равно придётся пилить код — чудес не бывает.
Есть у меня большие сомнения в том, что такой подход будет реально работать для большой, нагруженной системы без дотачивания кода. В частности, что там с автономными транзакциями, хинтами, MERGE, вложенными транзакциями, различиями в реализации версионности... Что-то мне подсказывает, что под нагрузкой с кодом, написанным для Oracle без учёта особенностей ядра PostgreSQL, будут проблемы, и придётся его переписывать.
Поделюсь своим опытом: в компании, где я работал, был инструмент, который позволял конвертировать более 90% кода с PL/SQL на PL/pgSQL. Проблемы обычно начинались дальше, уже в эксплуатации, т. к. ядра СУБД отличаются, и какие-то подходы, которые были хороши для Oracle, для PostgreSQL были смерти подобны — и наоборот. В нашем случае мы могли поменять уже код на PL/pgSQL, и мне кажется, это более удобно. К тому же результирующий код можно было исполнять на ванильной версии, т. е. тут, в отличие от Digital Q.DataBase, не было вендор-лока.
То что не видно не значит что этого нет :). Мы мигрировали не АБС конечно, но ERP/MES систему в которой вся бизнес логика была на PL/SQL (порядка 4 тыс пакетов) по итогам конвертации получилось больше 500 тыс строк кода. И да такое конечно не через ora2pg делается у нас был свой инструмент для конвертации кода (без всякого AI только православный yacc), и сам код под Oracle пришлось адаптировать там где автоматическая конвертация не справлялась. Думаю и АБС таким же образом можно перевести тут дело не сколько в коде на сервере сколько в объемах и дальнейшей эксплуатации ибо нюансов много и обычно да же после хорошего тестирования оно все уже под нагрузкой начинает лезть.
К сожалению, не всё можно быстро доработать — между ядрами баз есть коренные отличия, которые в конечном счёте влияют на то, как мы пишем код. Приведу простой пример: допустим, у вас есть хранимая функция, которая делает какой-нибудь сложный расчёт в течение, скажем, часа, при этом активно обновляет данные во временной таблице. Такой код будет нормально работать на Oracle, но если его перенести на PostgreSQL, расчёт может не завершиться никогда — из-за bloating. В результате придётся переписывать код под базу.
Или другой пример: допустим, архитектура системы построена на длинных транзакциях, и в коде активно используются конструкции вида
begin -- что-то пишем в базу exception end. При переходе на Postgres получим проблемы с LWLock, а возможно, и со счётчиком транзакций. И опять же, нужно будет править код функций.В общем, для того чтобы быстро показать импортозамещение — вариант очень хороший. А вот для реальной работы под нагрузкой всё равно придётся пилить код — чудес не бывает.
Есть у меня большие сомнения в том, что такой подход будет реально работать для большой, нагруженной системы без дотачивания кода. В частности, что там с автономными транзакциями, хинтами, MERGE, вложенными транзакциями, различиями в реализации версионности... Что-то мне подсказывает, что под нагрузкой с кодом, написанным для Oracle без учёта особенностей ядра PostgreSQL, будут проблемы, и придётся его переписывать.
Поделюсь своим опытом: в компании, где я работал, был инструмент, который позволял конвертировать более 90% кода с PL/SQL на PL/pgSQL. Проблемы обычно начинались дальше, уже в эксплуатации, т. к. ядра СУБД отличаются, и какие-то подходы, которые были хороши для Oracle, для PostgreSQL были смерти подобны — и наоборот. В нашем случае мы могли поменять уже код на PL/pgSQL, и мне кажется, это более удобно. К тому же результирующий код можно было исполнять на ванильной версии, т. е. тут, в отличие от Digital Q.DataBase, не было вендор-лока.
То что не видно не значит что этого нет :). Мы мигрировали не АБС конечно, но ERP/MES систему в которой вся бизнес логика была на PL/SQL (порядка 4 тыс пакетов) по итогам конвертации получилось больше 500 тыс строк кода. И да такое конечно не через ora2pg делается у нас был свой инструмент для конвертации кода (без всякого AI только православный yacc), и сам код под Oracle пришлось адаптировать там где автоматическая конвертация не справлялась. Думаю и АБС таким же образом можно перевести тут дело не сколько в коде на сервере сколько в объемах и дальнейшей эксплуатации ибо нюансов много и обычно да же после хорошего тестирования оно все уже под нагрузкой начинает лезть.