Конфигурирование среды разработки баз данных вместе с Hibernate и Spring - PullRequest
Новая
       10

Конфигурирование среды разработки баз данных вместе с Hibernate и Spring

0 голосов
/ 18 мая 2018

У нас есть веб-приложение в фазе разработки, где мы используем Spring 5, JPA (Hibernate) и Postgresql 9.4

До этого момента мы использовали один экземпляр posgresql db для нашей работы.По сути, у нас нет сценария генерации схемы, и мы просто обновляли базу данных, если нам нужна была новая таблица, столбец и т. Д. Для Hibernate мы генерировали классы из базы данных.

Теперь, когда у нас есть некоторое количество тестовых данных, и каждое изменение в БД доставляет много хлопот и путаницы.Мы поняли, что нам нужно создать и начать поддерживать некоторый файл генерации схемы вместе с некоторыми скриптами, которые генерируют тестовые данные.

После некоторых исследований мы видим два варианта

  1. Создатьдва * .sql файла.Первый будет содержать скрипт генерации схемы, второй - SQL для создания тестовых данных.Затем добавьте небольшой модуль с классом, который будет выполнять файлы * .sql, используя обычный jdbc.По сути, мы продолжим разработку, и всякий раз, когда мы вносим некоторые изменения, мы быстро стираем-> создаем-> заполняем базу данных.Этот подход выглядит наиболее привлекательным для нас на данный момент.Это быстро, просто, надежно.

  2. Во-вторых, необходимо настроить какой-либо инструмент, который может помочь с этим, например Liquibase Этот подход также выглядит хорошо с точки зрения поддержки версий идругие возможности.Однако мы еще не в производстве, мы находимся в активной фазе разработки.У нас не так много разработчиков, которые вносят изменения в БД, и мы не уверены, как часто мы будем обновлять схему БД в производстве, это может быть редко.

Вопрос в том,следующие.Будет ли первый подход плохой практикой, а применение второго принесет наибольшую пользу, и стоит ли его использовать?

Буду признателен за любые комментарии или любые другие предложения!

Ответы [ 2 ]

0 голосов
/ 18 мая 2018

Первый подход НЕ является плохой практикой, до этого поколения.Но это будет учитывать рост таких инструментов, как Liquibase.

Если вы находитесь на ранней или средней фазе разработки, переходите к LiquiBase вместе с Spring Data.Наоборот, на завершающих этапах фазы разработки думайте, что вам это действительно нужно.

0 голосов
/ 18 мая 2018

Я бы предложил второй подход, так как он автоматически найдет новый скрипт при добавлении и запуске скрипта при запуске.Более того, если у вас есть инструменты, такие как liquibase и flyway, зачем изобретать велосипед?

2-й подход также уменьшит ненужный код для ручного выполнения файлов * .sql.Кроме того, этот код также нуждается в тестировании, и в случае обновления он может быть подвержен ошибкам.

Более того, 1-й подход, при котором вы пишете ручной код для выполнения сценария, также должен проверять, какие сценарии должны быть выполнены. Если у вас уже есть существующая база данных иВы добавляете несколько новых сценариев, которые вам нужны только для выполнения этих новых сценариев.Эти вещи решаются автоматически при втором подходе, и вам не нужно беспокоиться о том, что уже выполненный сценарий будет выполнен снова

Надеюсь, это отвечает вашим интересам.Счастливое кодирование

...