Рекомендации по созданию схемы Hibernate / JPA DB

Question

Мне просто хотелось услышать мнение экспертов Hibernate о лучших методах создания схем БД для проектов на основе Hibernate / JPA. Особенно:

1. Какую стратегию использовать, когда проект только начался? Рекомендуется ли Hibernate автоматически генерировать схему на этом этапе или лучше создавать таблицы базы данных вручную с самых ранних этапов проекта?

2. Делая вид, что на протяжении всего проекта схема генерировалась с помощью Hibernate, лучше ли отключить автоматическое создание схемы и вручную создать схему базы данных непосредственно перед тем, как система будет запущена в производство?

3. А после того, как система будет запущена в производство, какова наилучшая практика для поддержки классов сущностей и схемы БД (например, добавление / переименование / обновление столбцов, переименование таблиц и т. 1014 *

Answer 1

1. Всегда рекомендуется генерировать схему вручную, желательно с помощью инструмента, поддерживающего ревизии схемы базы данных, например, Liquibase . Генерация схемы из сущностей великолепна в теории, но на практике она была хрупкой и в долгосрочной перспективе вызывает множество проблем (поверьте мне):

2. В производственных процессах всегда лучше создать схему вручную и просмотреть схему.

3. Вы вносите обновление в сущность и создаете соответствующий скрипт обновления (ревизия), чтобы обновить схему базы данных, чтобы отразить изменение сущности. Вы можете создать собственное решение (я написал несколько) или использовать что-то более популярное, например liquibase (он даже поддерживает откат изменений схемы). Если вы используете инструмент сборки, такой как maven или ant - рекомендуется подключить утилиту обновления схемы db к процессу сборки, чтобы свежие сборки синхронизировались со схемой.

Answer 2

Хотя спорно, я бы сказал, что ответ на все 3 вопроса является:. Пусть спящий режим автоматически генерировать таблицы в схеме

1002 * У меня не было никаких проблем с этим до сих пор.Вам может понадобиться время от времени очищать некоторые поля вручную, но это не головная боль по сравнению с раздельным отслеживанием сценариев DDL - т.е. управляет их ревизиями и синхронизирует их с изменениями сущностей (и наоборот)

Для развертывания в рабочей среде - очевидный совет - сначала убедитесь, что в тестовой среде все создано правильно, а затем разверните в рабочей среде.

Answer 3

Вручную, потому что:

1. Одна и та же база данных может использоваться разными приложениями и не все они будут использовать Hibernate или даже Java. Схема базы данных должна ORM не должен быть продиктован, он должен быть основан на данных и бизнес-требования.
2. Типы данных, выбранные hibernate, могут не подходить для данного приложения.
3. Как упоминалось в предыдущем комментарии, изменения в объектах потребуют ручного вмешательства, если потеря данных неприемлема.
4. Такие вещи, как дополнительные свойства (общий термин не Java свойства) в таблицах соединения прекрасно работают в RDBMS, но несколько сложный и неэффективный для использования в ORM. Делать такое отображение из ORM -> RDBMS может создавать таблицы, которые не являются эффективный. Теоретически возможно построить точно такое же соединение таблица с использованием сгенерированного кода Hibernate, но это потребует некоторых особое внимание при написании сущностей.

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

Answer 4

Как сказал Божидар, не позволяйте Hibernate создавать и обновлять схему базы данных. Позвольте вашему приложению создать и обновить схему базы данных. Для Java лучший инструмент для этого - Flyway . Вам необходимо создать один или несколько файлов SQL с операторами DDL, которые описывают схему вашей базы данных. Эти файлы SQL затем выполняются Flyway. Для получения дополнительной информации посмотрите на сайте Flyway .

Answer 5

Я полагаю, что многое из того, что обсуждается или обсуждается здесь, также должно быть связано с тем, что вам больше нравится подход с использованием кода или базы данных.

Лично я более намеренчтобы перейти к последнему пункту, и, ссылаясь на принцип единой ответственности (SRP), я предпочитаю иметь специалиста по БД, обрабатывающего БД, и специалиста по приложениям, обрабатывающего приложение, чем иметь приложение, обрабатывающее БД.Кроме того, я придерживаюсь мнения, что поначалу использование слишком большого количества ярлыков будет работать нормально, но создает неуправляемые проблемы по мере роста / развития.