Как мы продукт на PostgreSQL переводили

[beduin01]

В Oracle повсеместно широко используют различные хранимые процедуры и триггеры. Как вы с ними вопрос решили?

[shaddyk]

Мы при развитии решения осознанно не выносили никакой бизнес-логики на БД --- триггеров в ней нет совсем, а десяток таки-появившихся хранимых процедур перенесли руками. Потребности в их автоматической миграции не возникло.

[artic_placebo]

Какие ещё варианты рассматривали кроме Pentaho? Почему не стали использовать ora2pg?

[shaddyk]

До Pentaho мы протестировали 5 вариантов: импорт/экспорт csv, dblink через гетерогенные сервисы оракла, dblink через oracle_fdw, ora2pg и SymmetricDS.

Ни один из них не давал нам возможности перелить полный объем в течение заявленного окна времени, а для итогового варианта с догрузкой дельт нам не хватало управляемости --- на тот момент ora2pg не умел забирать часть данных из таблицы, переливал её всегда целиком. Может сейчас научился?

[MiIs]

С другой стороны сильно порадовал богатый DDL и DML синтаксис. У любого CREATE INDEX и ADD COLUMN есть опция IF NOT EXISTS. Это после Oracle, где для безопасного создания индекса, надо писать солидный блок кода

1. В Oracle DB 23c "IF NOT EXISTS" уже тоже имеется: https://docs.oracle.com/en/database/oracle/oracle-database/23/sqlrf/CREATE-TABLE.html#GUID-F9CE0CC3-13AE-4744-A43C-EAC7A71AAAB6

2. В более ранних версиях Oracle для удобства в PL/SQL пакете Один раз писались соответствующие процедуры и дальше пользовались всегда. Типа,

PROCEDURE CREATE_TABLE_IF_NOT_EXISTS (p_owner IN STRING, p_table_name IN STRING. p_table_definition IN STRING) ...

3. Oralce был и остается на данный момент лучшей реляционной базой данных в мире. Однако политика правительства США ведет нас к тому, что рано или поздно придется от него отказаться. Но лично я не особо вижу переходить с Oracle на что-то другое в авральном режиме, где на этой базе уже есть работающие продукты или решения. "Легитимные" для России версии Oracle 19C и даже 21С могут проработать еще лет 10 а то и больше, не особо устаревая. Главное, чтобы железо под них было подходящее. Как там, правило программистов "Не трогай работающую систему". Ну а все новые проекты, конечно же надо начинать на чем-то другом.

[shaddyk]

1. Ура, дозрели! Синтаксический сахар — это приятно.

2. Наше решение использовалось вместе с зоопарком от 9 до 21 версий Оракла, универсального подхода для всех сразу не получилось. Но да, в итоге все это сводится к хранимкам — у нас такие тоже были.

3. Аврального перехода и не происходит, но мотивация переходящих вполне понятна — патчи для возникающих ошибок теперь получить можно только с помощью сложных схем, да и в целом любое обращение в саппорт превращается в настоящий квест. Так что для промышленной эксплуатации приличных систем использовать Oracle уже не так приятно.
   А вот с мыслью о том, что Oracle — лучшая реляционная БД, я соглашусь. Оптимизатор, диагностика, стабильность работы... Эх :)

[Hafmaer]

Отличная статья, коррелирует с моим опытом миграции крупной БД Axapta 3.0 в "нереально сжатый срок простоя продуктива", но плюс пересчет RecId int32 (кто работал знает проблему с ограничением maxint на компанию).