Хороший вопрос, спасибо. Да, есть еще одна неописанная с статье проблема, которая может потянуть существенные изменения в коде. Это значения null и пустые (''). Если в Oracle это одно и то же значение, то в Postgres - это разные значения. И если в таблицы Oracle вставлялись пустые значения (''), и в таблице они сохранялись как null, то теперь в таблицах Postgres будет уже пусто (''), а не null для текстовых полей и ошибка для числовых. Если с числовыми полями тестирование выявит запросы (выпадут ошибки), то с текстовыми сложнее - строки в таблицу вставятся, а в дальнейшем запросы типа 'where поле is [not] null' будут работать с точность до наоборот. Что здесь можно предложить - либо сканировать строки в таблицах Postgres на поиск '', либо ставить ограничение на текстовые поля 'CHECK (text_column <> '' OR text_column IS NULL)', чтобы вставка '' выдавала ошибку. К сожалению, из базы данных Oracle никаким способом мы не получим запросы, в которых в переменных подстановки (bind) используете '' вместо null. Даже если бы insert/update попали бы в представления v$sql_bind_capture / v$active_session_history (что вряд ли), в значениях bind будет пусто (т.е. null) и для '', и для null. Даже в trace-файлах не будет разницы.
Еще 1 момент - конкатенация с NULL-значением. В Postgres она выдаст NULL, в Oracle - значение: '1'||null = '1' в Oracle '1'||null = null в Postgres Нужно проверить все конкатенации в запросах и поставить nvl/coalesce при необходимости.
По производительности в нашем случае проблем не было замечено (база небольшая), хотя, конечно, они возможны. Например, с теми же null - в postgres по умолчанию строки с null ключом попадают в индекс, а в Oracle - нет. Если на это закладывались в Oracle, то может возникнуть проблема производительности, которая легко решается в Postgres частичным индексом. Железо мы все-таки брали более мощное и по процессорам на всякий случай и по памяти, которой для Postgres нужно больше.
Хороший вопрос, спасибо.
Да, есть еще одна неописанная с статье проблема, которая может потянуть существенные изменения в коде. Это значения null и пустые (''). Если в Oracle это одно и то же значение, то в Postgres - это разные значения. И если в таблицы Oracle вставлялись пустые значения (''), и в таблице они сохранялись как null, то теперь в таблицах Postgres будет уже пусто (''), а не null для текстовых полей и ошибка для числовых. Если с числовыми полями тестирование выявит запросы (выпадут ошибки), то с текстовыми сложнее - строки в таблицу вставятся, а в дальнейшем запросы типа 'where поле is [not] null' будут работать с точность до наоборот. Что здесь можно предложить - либо сканировать строки в таблицах Postgres на поиск '', либо ставить ограничение на текстовые поля 'CHECK (text_column <> '' OR text_column IS NULL)', чтобы вставка '' выдавала ошибку.
К сожалению, из базы данных Oracle никаким способом мы не получим запросы, в которых в переменных подстановки (bind) используете '' вместо null. Даже если бы insert/update попали бы в представления v$sql_bind_capture / v$active_session_history (что вряд ли), в значениях bind будет пусто (т.е. null) и для '', и для null. Даже в trace-файлах не будет разницы.
Еще 1 момент - конкатенация с NULL-значением. В Postgres она выдаст NULL, в Oracle - значение:
'1'||null = '1' в Oracle
'1'||null = null в Postgres
Нужно проверить все конкатенации в запросах и поставить nvl/coalesce при необходимости.
По производительности в нашем случае проблем не было замечено (база небольшая), хотя, конечно, они возможны. Например, с теми же null - в postgres по умолчанию строки с null ключом попадают в индекс, а в Oracle - нет. Если на это закладывались в Oracle, то может возникнуть проблема производительности, которая легко решается в Postgres частичным индексом. Железо мы все-таки брали более мощное и по процессорам на всякий случай и по памяти, которой для Postgres нужно больше.