Работа с несколькими схемами базы данных

Question

Существует стороннее приложение, к базе данных которого обращается мое приложение. Его схема базы данных менялась несколько раз, поэтому сейчас существует около четырех разных схем базы данных (разные столбцы, разные условия выбора для одних и тех же объектов).

Например, существует сущность «Приложение». Для разных схем его можно получить по:

1) SELECT * FROM apps WHERE cell_number < 65535 AND page_number < 65535 AND top_number = 65535

2) SELECT * FROM menu_item WHERE cell_number > -1 AND page_number > -1 AND parent_id = -1 AND component_name IS NOT NULL

И так далее ...

Итак, какой шаблон проектирования (в Java) будет более удобным для поддержки нескольких схем баз данных разных версий одного и того же приложения? Конечно, он должен быть готов к будущим изменениям.

Answer 1

Это не простая задача, потому что трудно правильно сопоставить структуру таблицы с объектом (в настоящее время для выполнения этой задачи часто используется ORM).

Из вашего вопроса кажется, что объявление Application как абстрактного классаили интерфейса и обеспечения другой реализации достаточно.

public abstract class Application(){
    public abstract Application getAnApplication();
}

public ConcreteApplicationOne(){
    public Application getAnApplication(){

      //retrieve application data from database scheama 1 , build object and return it.
    }
}

public ConcreteApplicationTwo(){
    public Application getAnApplication(){

      //retrieve application data from database scheama 2 , build object and return it.
    }
}

И использование какой-то фабрики для сборки дает пользователю правильный конкретный класс Application:

public class factory {public Application getApplicationImplementation () {if (cond1) {вернуть новый ConcreteApplicationOne ();} else {return new ConcreteApplicationTwo ();}}}

Answer 2

Я считаю, что решение вашей проблемы состоит в том, чтобы определить классы данных в вашем приложении и использовать ORM, например Hibernate, для генерации таблиц базы данных в вашей БД. Вам нужно будет проверить функциональность миграции. Пожалуйста, ознакомьтесь со следующей статьей, в которой говорится об этой теме:

Гибернация и миграция БД

Переместив структуру данных в основной код, вы получите следующее:

• Нет необходимости хранить код и логику в двух местах и ​​на двух языках
• Проще проверить, так как в БД нет логики
• Скрипт миграции может быть сгенерирован автоматически