Вы можете выбрать, разрешать ли Hibernate управлять вашей схемой или нет. Если да, схема базы данных будет создана или обновлена на основе изменений в отображении аннотации.
Я лично не позволю Hibernate управлять своей схемой базы данных, так как я хочу точно знать, что происходит с изменениями схемы. Документация hibernate также предлагает это как-то:
Хотя автоматическая генерация схемы c очень полезна для целей тестирования и создания прототипов, в производственной среде она гораздо более гибка управлять схемой, используя сценарии инкрементной миграции.
, в то время как Flyway, Liquibase является своего рода инструментом сценариев инкрементной миграции.
Нужно ли настраивать его обоими способами, или достаточно ли сделать в SQL? И как часто SQL миграций используются (Flyway, Liquibase) в проектах?
Если вы не используете функцию автоматической генерации c схемы, вам не нужно указывать unique в @Column, который имеет значение только в случае автоматической c генерации схемы.
Для nullable это зависит от настройки hibernate.check_nullability. Если она включена и вы задаете @Column(nullable=false), Hibernate поможет проверить, что этот столбец не может быть нулевым на уровне приложения, не попросив БД проверить его. Но даже если он не установлен, ограничение базы данных (при условии, что вы создаете ненулевое ограничение для него в БД) в конечном итоге проверит его и не позволит сохранить нулевое значение