2026-01-20 21:46

Аутстаффинг разработчика БД: перенос Oracle Reports на PostgreSQL и XSQUARE

В проектах импортозамещения одна из самых скольких частей — вовсе не перенос схемы БД, а миграция отчетности и связанной с ней логики. Отчеты часто завязаны на специфичные функции 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 подключит выделенного специалиста. Эксперт легко вольется в вашу команду и будет работать по всем внутренним регламентам и процессам.