В проектах импортозамещения одна из самых скольких частей — вовсе не перенос схемы БД, а миграция отчетности и связанной с ней логики. Отчеты часто завязаны на специфичные функции Oracle, процедуры, пакеты, особенности SQL-диалекта и тонкости производительности. Если перенести их формально, заказчик получает регрессы, плавающие цифры и долгую стабилизацию.
Российской IT-компании, которая внедряет и сопровождает корпоративные информационные системы для финсектора, потребовался разработчик БД на аутстаффинге. Команда iStaff-it подключила выделенного специалиста, который взял на себя перенос отчетов и серверной логики на PostgreSQL и отечественную low-code платформу, а также помог с оптимизацией запросов и документацией.
Как перенесли отчеты Oracle в новый контур без потери логики
Система формировала отчетность на Oracle: SQL и PL/SQL использовались вместе с отчетными шаблонами (Oracle Reports). При миграции важно было сохранить не только их внешний вид, но и правила расчета, фильтры, сортировки, агрегации, форматы валют и паттерны поведения при «пустых» строках. Поэтому работу начали с инвентаризации и анализа того, где именно живет логика: в запросах, процедурах, параметрах или в слоях формирования данных.
Дальше специалист последовательно переносил объекты и заменял Oracle-специфику на эквиваленты PostgreSQL, проверяя результаты на тестовых выборках и сценариях использования. Под адаптацию попали:
- SQL-запросы и блоки логики, используемые в отчетах (включая параметры, условия, агрегации).
- PL/SQL-участки, связанные с подготовкой данных под различную отчетность.
- Вычисляемые поля, правила форматирования и структуры выдачи.
- Связанные справочники/представления, от которых зависели отчеты.
- Сценарии запуска и типовые пользовательские фильтры.
После каждого пакета изменений нашим специалистом с опытом работы с PostgreSQL фиксировались контрольные точки. Какие отчеты перенесены? Какие зависимости закрыты? Что требует оптимизации, а что можно выпускать в контур без риска для пользователей?
Переписывание PL/SQL на PL/pgSQL — аккуратная замена
Перенос процедурного кода обычно ломается не на синтаксисе, а на поведении. На обработке NULL и работе с датами, строками, типами, курсорами, исключениями и транзакционностью. Поэтому специалист не «переводил» PL/SQL механически, а сначала разбирал назначение модулей: какие входные параметры, какие условия, где формируются временные наборы, как рассчитываются итоги и что считается ошибкой.
Затем код переносился на PL/pgSQL с сохранением читаемости и поддержки, чтобы внутренней команде было проще развивать решение после миграции. Эксперт iStaff-it:
- разбирал исходный код и выделял участки, критичные для расчетов и сверок;
- переписывал процедуры и функции на PL/pgSQL с учетом различий диалектов Oracle и PostgreSQL;
- согласовывал структуру возвращаемых данных (в т.ч. для отчетных форматов и интерфейсов);
- подключал проверки и «страховки» от типовых ошибок (пустые выборки, неожиданные типы, NULL);
- описывал принятые решения в документации: что перенесено один в один, а где логика переосмыслена под PostgreSQL.
После переноса логики силами нашего Oracle-разработчика, команда получала не просто «работает», а понятную базу для поддержки — где лежат расчеты, как они устроены и на что завязаны.
Отчетные формы и интерфейсы на отечественной low-code платформе
Помимо серверной части, нужно было восстановить слой пользовательской работы с отчетами: формы параметров, сценарии запуска, отображение результатов, экспорт и служебные атрибуты. Для этого использовалась отечественная low-code платформа, а часть интерфейсной логики реализовывалась привычным веб-стеком — HTML/CSS/JavaScript.
Специалист собирал формы, чтобы они повторяли сценарии исходной системы. С понятными параметрами, подсказками, предустановками и валидными значениями — без лишних ручных шагов. В этот блок работ вошли следующие процессы:
- создание форм пользовательского интерфейса под запуск и настройку отчетов;
- разработка отчетных форм, где выдача формируется через PL/pgSQL и передается в нужном формате (в т.ч. JSON);
- привязка параметров формы к запросам и процедурам на стороне PostgreSQL;
- проверки корректности ввода (диапазоны дат, обязательные поля, допустимые значения);
- подготовка описаний для документации: какие поля и параметры за что отвечают.
Разработчик баз данных PostgreSQL добился создания интерфейса, сопоставимого с прежнем опытом пользователей. При этом расчетная часть осталась управляемой и прозрачной на уровне обращения с БД.
Производительность на PostgreSQL — планы запросов и предсказуемое время формирования отчетов
Отчетность часто нагружает БД «пиково»: один запуск — и тяжелые агрегации начинают конкурировать за ресурсы с другими транзакциями и запросами. Поэтому отдельный блок работ — анализ планов запросов и оптимизация. Здесь важно не «ускорить любой ценой», а добиться стабильного времени ответа в типовых режимах (на реальных объемах данных и с рабочими фильтрами пользователей).
Специалист анализировал планы, смотрел узкие места и предлагал изменения, которые не ломают логику — переписывание запросов, корректировка условий, снижение лишних вычислений, работа с индексами и статистикой. В числе мер оптимизации, которые применялись на проекте:
- Анализ планов запросов и поиск самых дорогих операций (сканы, сортировки, агрегации).
- Переписывание запросов под PostgreSQL-оптимизатор без изменения результата.
- Проверка корректности индексации под частые фильтры и соединения.
- Уточнение форматов выдачи и состава полей там, где это влияло на объем данных.
- Фиксация рекомендаций и допущений в документации, чтобы не потерять решения при дальнейших доработках.
Так удалось снизить риск «сюрпризов» после релиза, когда формально перенесенный отчет начинает работать в разы медленнее.
Итог работ и роль эксперта iStaff-it
За 1 243 часа выделенный разработчик баз данных помог перенести отчетность и связанную серверную логику с Oracle-стека на PostgreSQL. А еще — собрать формы на отечественной low-code платформе и пройтись по производительности там, где отчеты упирались в планы запросов. Параллельно специалист участвовал в подготовке технической документации, чтобы у команды заказчика оставалась понятная база для поддержки и развития.
Если вам нужен разработчик БД под миграцию с Oracle на PostgreSQL с фокусом на отчетность, процедурный код и высокую производительность — iStaff-it подключит выделенного специалиста. Эксперт легко вольется в вашу команду и будет работать по всем внутренним регламентам и процессам.
