СУБД Oracle Специфичные данные приложения Учетная машина (таблицы и хранимые процедуры) Невысокая нагрузка Небольшое количество пользователей Сезонная нагрузка 3/20
абстракции Остается возможность неконтролируемой работы с данными Шаблон Repository Ограничивает доступ к сущностям Определяет четкий интерфейс для работы с данными 7/20
поверх Hibernate Подключаем и настраиваем Spring Data Создаем репозитории Объявляем интерфейс Настраиваем методы query Пишем custom реализацию, если нужно Используем Specification с JPA Criteria API Выделяем native queries в отдельные компоненты 8/20
количества запросов со спецификой Oracle В расчетных полях сущностей В отчетах и некоторых компонентах (нативные запросы) Наличие модульных тестов помогает быстро локализовать такие места в коде 10/20
на PostgreSQL На данный момент полный перевод не выполнен Логика учета и необходимые ей данные содержатся в Oracle Данные приложения переезжают в PostgreSQL Необходимо решение для гибридного доступа 11/20
Virtual Database (VDB) Установка и настройка Teiid Designer Импорт структуры таблиц в Teiid Designer «Доработка напильником» Настройка типов данных Настройка вызовов хранимых процедур … Настройка на физические СУБД Установка и запуск VDB 14/20
своей разработки Планы запросов И сделали следующее: Вынесли ряд таблиц в кэш Teiid Оптимизировали join данных в ряде запросов В результате показатели приблизились к Oracle 17/20
недорого Следование принципу DAL существенно облегчает переезд на аналогичную СУБД Если много логики АС находится в СУБД, стоит рассмотреть промежуточный вариант перевода (с гетерогенным доступом к данным) А если DAL – и в масштабе предприятия? 18/20