Создание баз данных в проектах hibernate

Если писать на Java то моделировать данные лучше на этом языке, нежели на языке БД. В этом случае используется прямой инжениринг в ООП, когда объекты создаются на Java и сохраняются в БД используя ОРМ фреймворк наподобие Hibernate.

С другой стороны есть обратный подход, который называется реверсным инжнирингом, при котором сначала моделируются объекты БД, а потом эти объекты маппятся на классы Java для создания объектов из них и сохранения в БД.

Все это возможно в рамках одного и того же ОРМ фреймворка Hibernate, который в свою очередь поддерживает различные БД и языковые диалекты. Эти диалекты помогают моделировать Java независимо от того какая БД используется физически. Это помогает легко поменять существующую БД, скажем с PostgreSQL на Oracle или на MySQL и наоборот.

Работа с БД и понятие "создание БД" в обычном проекте включает несколько активностей:

1. создание собственно сервера СУБД и пустой БД на нем
2. создание структуры таблиц приложения
3. изменение структуры таблиц. Cюда включается: добавление/удаление/переименование полей, перенос полей в другие таблицы, добавление/удаление/переименование таблиц, изменения типа полей, добавление ограничений, создание связей между таблицами и т.п.
4. работа с данными в базе: создание/чтение/изменение/удаление записей в БД

Cозданием сервера СУБД и пустой БД занимаются администаторы БД или специалисты devops. Это я включил для полноты картины, т.к. это тоже можно трактовать как "создание БД".

Cоздание структуры таблиц приложения (имеется ввиду с нуля) и дальнейшее изменение структуры таблиц делают с использованием инструментов для миграции баз данных. hibernate умеет делать нормально только первую часть, т.е. начальное создание таблиц, но не умеет делать изменение структуры (об этом подробнее ниже). В качестве таких инструметов используются liquibase и flyway, иногда самописные инструменты.

Поясню почему так важно уметь мигрировать БД. В процессе жизненного цикла приложения возникает необходимость вносить изменения в структуру БД. Это может быть вызвано необходимостью добавить новый функционал в приложение (хранить новую сущность в БД или добавить поля в существующую), или изменить существующий (например, чтоб хранить для пользователя не один а несколько телефонов может потребоваться перенести эти данные из поля в таблице user в отдельную таблицу user_phone) или исправить ошибку (например, когда выбраный изначально тип поля integer оказался слишком мал и нужно заменить его на bigint) или изменить способ хранения данных, чтоб оптимизировать медленные операции.

Надеюсь идея понятна, такая необходимость возникает постоянно, и нужно уметь это делать.

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

Вторая проблема, что в этом подходе нельзя сделать автоматическое разворачивание системы. Поэтому процедуру изменения структуры БД (по другому - миграцию БД) автоматизируют. Сами команды для миграций хранят вместе с кодом в системе контроля версий. Чтоб всегда и на любой системе можно было привести БД в состояние соответствующее коду.

Теперь несколько слов почему для этого не годится хибренейт. Хибернейт умеет только:

1. создавать БД с нуля
2. при изменениях (за это отвечает свойство hbm2ddl.auto):

• либо уничтожать все данные и опять создать все с нуля
• или ничего в БД не менять.
• или менять структуру в БД

Подход "уничтожить и создать с нуля" - не годится, так как все данные, что пользователь создавал, может быть годы, будут уничтожены. Ничего не менять - это невозможность изменять структуру вообще, а как мы уже убедились, в нетривиальном приложении без этого редко обходится.

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