Я просто хотел услышать, что мнение о В спящем режиме, эксперты о лучших практиках поколения схемы DB для Hibernate/JPA основывали проекты. Особенно:
Какую стратегию использовать, когда проект только что запустился? Рекомендуется позволить, в спящем режиме, автоматически генерируют схему в этой фазе, или лучше создать таблицы базы данных вручную из самых ранних фаз проекта?
Притворение, что в течение проекта схема была сгенерирована с помощью, в спящем режиме, лучше отключить автоматическое поколение схемы и вручную создать схему базы данных непосредственно перед тем, как система выпущена в производство?
И после того, как система была выпущена в производство, какова лучшая практика для поддержания классов объекта и схемы DB (например, столбцы добавления/переименования/обновления, переименование таблиц, и т.д.)?
Всегда рекомендуется генерировать схему вручную, предпочтительно с помощью инструмента, поддерживающего изменения схемы базы данных, например, великой Liquibase . Создание схемы из сущностей - это прекрасно в теории, но на практике было хрупким и в конечном итоге вызывает множество проблем (поверьте мне).
В производстве всегда лучше создать схему вручную и просмотреть ее.
Вы обновляете объект и создаете соответствующий сценарий обновления (ревизию), чтобы обновить схему базы данных, чтобы отразить изменение объекта. Вы можете создать собственное решение (я написал несколько) или использовать что-нибудь более популярное, например Liquibase (оно даже поддерживает откаты изменений схемы). Если вы используете инструмент сборки, такой как maven или ant, рекомендуется подключить утилиту обновления схемы db к процессу сборки, чтобы свежие сборки оставались синхронизированными со схемой.
Хотя это спорно, я бы сказал, что ответ на все 3 вопроса таков: позвольте спящему режиму автоматически генерировать таблицы в схеме.
У меня пока с этим не было проблем. Возможно, вам придется время от времени очищать какое-то поле вручную, но это не головная боль по сравнению с отдельным отслеживанием сценариев DDL, то есть управлением их версиями и синхронизацией их с изменениями сущностей (и наоборот)
Для развертывания на production - очевидный совет - сначала убедитесь, что все сгенерировано нормально в тестовой среде, а затем разверните в производственной среде.