Comments 4
Очень интересно, с нетерпением жду следующих частей
Интересно, но на сложных процедурах все это споткнется
Спасибо за отклик.
Речь идет не столько о сложности процедур, а о том, что написание парсера для конкретного
случая самая дорогая операция и Вы должны, четко понимать конечную эффективность. Я использую термин покрытие.
Чем больше процедур Вы покроете тем целесообразнее потраченное время.
Наоборот чем сложнее и уникальнее преобразование, тем больше повод подумать написать этот кусок в ручную.
Подход реально используется для систем анализа систем автоматического страхования, которые представляют набор правил на javascript (rule set).
Цель - создания репортов описывающих правила принятия страховых решений в виде таблиц решений (if конструкции преобразуются в таблицы решений) а также нахождение ошибок в правилах принятия решений. Наборы разные содержат тысячи правил, нигде нет 100% покрытия.
Но покрытие 70-80% вполне достижимо.
Т.е. к примеру часть процедур не будет до конца рабочими и Вы будете знать эти места.
Может кому пригодится для проверки результатов переноса - Windows GUI для сравнения и синхронизации:
https://ksdbmerge.tools/cross-dbms-diff-merge-overview.html
есть бесплатная версия которая позволяет сравнить две произвольные таблицы между MSSQL и постгресом, настроить мапинг если имена таблицы и/или полей не совпадают (я автор)
ETL процесс для миграции процедур с mssql на postgreSQL. Часть 1. Введение