Миграция с Oracle и MS SQL без переписывания кода: реальность или миф?
Импортозамещение в IT-индустрии – это не просто тренд, а необходимость. Но как перейти на российские СУБД, не потеряв годы разработки и миллионы строк кода?
Проблема, о которой не принято говорить
Если посмотреть на рынок отечественных баз данных, то многие решения выглядят одинаково: берут PostgreSQL, добавляют российское шифрование, популярные расширения, регистрируют продукт – готово. Звучит неплохо, но есть нюанс: ваша хранимая логика все равно не заработает.
Процедуры на PL/SQL из Oracle? Переписывать. Код на T-SQL из MS SQL Server? Тоже переписывать. А это месяцы работы, риски, ошибки и огромные бюджеты.
Как решают эту проблему в мире?
Существует два глобальных подхода к миграции:
Подход №1: Все переписать
Чистый лист. Новая архитектура. Идеальный код под PostgreSQL. Некоторым компаниям это подходит, но давайте честно: это дорого, долго и рискованно. В России есть инструменты миграции, но они автоматизируют лишь часть процесса.
Подход №2: Научить СУБД понимать «чужие» диалекты
Вместо переписывания кода – адаптировать базу данных. Именно этот путь выбрали крупнейшие игроки:
- Amazon разработал поддержку T-SQL поверх PostgreSQL для плавной миграции с Microsoft
- Южная Корея создала Tibero (сейчас TmaxData) – полностью Oracle-совместимую СУБД, которую использовала даже НСПК (Национальная система платежных карт)
- Alibaba Cloud запустил ProximaDB for Oracle – облачное решение с нативной поддержкой Oracle-синтаксиса
Российское решение: Digital Q.DataBase от Диасофт
Диасофт применил тот же подход в своей СУБД Digital Q.DataBase. Продукт построен на базе PostgreSQL, но с критичным отличием – он выполняет процедуры на PL/SQL и T-SQL без изменений.
Как это работает на практике?
Представьте: у вас есть процедура для Oracle на PL/SQL. Обычно ее нужно переделывать под PostgreSQL – менять синтаксис, типы данных, системные функции.
В Digital Q.DataBase вы запускаете ее как есть.
Пример для Oracle:
- Работает синтаксис PL/SQL, включая пакеты
- Поддерживаются типы данных Oracle
- Доступны UTL- и DBMS-пакеты
- Конструкции %type, %rowtype, %rowcount
- Пользовательские типы и nested tables
- Встроенные функции из официальной документации Oracle
- Библиотека, эмулирующая Oracle Instant Client
Пример для MS SQL Server:
- Полная поддержка синтаксиса T-SQL
- IDENTITY-поля и конструкции вроде @@IDENTITY
- Процедуры с OUTPUT и IN/OUT параметрами
- Системные таблицы, представления и sp_-процедуры
- Подключение по протоколу TDS — внешние приложения «думают», что это настоящий MS SQL Server
Реальный код, реальный результат
В статье приведен полноценный пример создания таблицы товаров, пакета с процедурами и функциями на PL/SQL. Код объемом более 100 строк выполняется без единого изменения.
То же самое с T-SQL: процедуры с транзакциями, OUTPUT-параметрами, обращениями к метаданным – все работает из коробки.
Почему это важно для бизнеса?
Экономия времени и денег
Не нужно тратить месяцы на переписывание тысяч процедур и функций. Ваши разработчики могут сосредоточиться на новых задачах, а не на «переводе» старого кода.
Минимизация рисков
Переписанный код = новые баги. Использование проверенной временем логики снижает вероятность ошибок в продакшене.
Сохранение экспертизы
Годы работы с Oracle или MS SQL не пропадают даром. Команда продолжает использовать знакомые инструменты и подходы.
Что дальше?
План развития Digital Q.DataBase:
- В ближайшее время — полная поддержка самых популярных DBMS-пакетов
- В перспективе пары лет — покрытие редко используемых функций
Уже сейчас уровень совместимости выше, чем у orafce для PostgreSQL, и сопоставим с Tibero.
Выводы
Импортозамещение не обязано быть болезненным. Современные технологии позволяют мигрировать на российские СУБД без переписывания всей бизнес-логики.
Подход «научить базу понимать чужие диалекты» доказал свою эффективность в мире — от Amazon до Alibaba. Теперь он доступен и в России.
Главный вопрос не «Можно ли?», а «Почему до сих пор не попробовали?»
Полная статья с примерами кода доступна на Хабр.