Лично мне не нравится экспортировать DDL по следующим причинам.
База данных, вероятно, является одним из наиболее важных компонентов инфраструктуры в приложениях, доверяя генерацию DDL средствам гибернации.что вы должны проверить весь DDL, сгенерированный hibernate, чтобы убедиться, что все в порядке, процесс проверки занимает столько же времени, сколько и написание DDL.
Когда пришло времяВыпустив новую версию приложения, у вас будет существующая база данных, и, следовательно, вы можете захотеть использовать операторы alter и использовать скрипт upgrade-to-version-x.sql для изменения существующей базы данных, чтобы новая база данных работалас новой версией.На этом этапе автоматическая генерация DDL вам не поможет, поскольку аннотированный класс hibernate только генерирует операторы CREATE, а не операторы ALTER DDL.
Аннотации Hibernate / JPA делятся на две категории: логические и физические.Логические аннотации - это такие вещи, как @Entity, а физические аннотации - такие, как @Table, @Columns ... и т. Д. В физических аннотациях недостаточно атрибутов, чтобы точно контролировать типы баз данных, которые генерируются для SQL.Например, скажем, у вас есть столбец, который содержит дату, и вы используете @ Column, @ аннотацию @ Temporal, обычно есть более одного типа данных базы данных, который подходит, доверять Hibernate для выбора значения по умолчанию, вероятно, не разумный шаг.
Всегда существуют конкретные рекомендации по базам данных, о которых hibernate не будет знать, но администратор базы данных будет знать.Например, если вы хотите создать индекс, нет способа указать это в аннотациях спящего режима или указать тип создаваемого индекса, например B-Tree, Bitmap ... и т. Д. Если аннотации JPA / Hibernateбыли расширены, чтобы позволить вам указывать все параметры, которые вы можете указать в специфичном для базы данных DDL, тогда аннотации будут более сложными, чем SQL, так как SQL очень хорошо построен для специфичного для домена языка, и аннотации никогда не будут такими же хорошими, как SQL DDL, они будут более многословными.Все, что вы в конечном итоге делаете, это сдвигаете сложность, не уменьшая ее.Подумайте обо всех языках конфигурации на основе XML, с которыми вы столкнулись, которые в конечном итоге будут увеличивать сложность до тех пор, пока они не станут похожи на реальный язык программирования с циклами на основе xml, если операторы, переменные ... etc
Если приложение растет и является успешным бизнес-приложением с большим количеством данных, вам в конечном итоге потребуется нанять администратора баз данных для настройки, оптимизации, зеркалирования базы данных и т. Д. Администратор базы данных будет знать лучшие практики для своей базы данных, но может и необязательно /, вероятно, не знаю Hibernate, что сделает жизнь администратора базы данных более сложной.Есть много изменений, которые DBA может внести в базу данных, которые не влияют на java-код на основе гибернации, действительно ли вы хотите, чтобы DBA изменил код hibernate для изменения настроек базы данных.После того, как администратор базы данных изменил настройки базы данных, теперь у вас есть две версии базы данных: экспортируемая версия из спящего и производственная, которая является реальной?
Лучшие практики проектирования баз данных и объектно-ориентированноеДизайн лучших практик не совпадает.Проектирование базы данных на основе объектов потенциально может означать отличный дизайн ОО, но не такой хороший дизайн БД, сначала проектирование БД, а затем объектно-ориентированного кода Hibernate может означать отличный дизайн БД, но не такой хороший дизайн спящего режима / ОО.С философской точки зрения я предпочитаю писать DDL вручную, чтобы переводить себя в режим проектирования баз данных, а не в режим проектирования ОО.В успешном приложении дизайн базы данных может пережить спящий режим на многие годы.То, что hibernate - это единственное, что говорит с базой данных сегодня, не означает, что это будет единственное, что будет говорить с базой данных в будущем.Поэтому я склонен ошибаться при оптимизации конструкций баз данных с использованием передовых методов проектирования баз данных, а не передовых OO.
Hibernate / ORM - это утечка абстракций, невозможно скрыть тот факт, что вы имеете дело с базой данных SQL, от разработчиков, если ваши разработчики не очень хорошо знают SQL, они, скорее всего, будут использовать hibernate в способы сделать базу данных узким местом. Личный опыт обучения людей в hibernate говорит мне, что вы должны понимать SQL еще лучше, чтобы эффективно использовать Hibernate. Вы должны уметь изучать HQL или какой-либо другой язык объектных запросов и мысленно переводить на SQL. Вам нужно будет знать, когда можно отобразить отношения и проследить их, используя запросы отчета. Вам нужно будет понять, почему потеря JOIN в запросах является такой проблемой. Я большой поклонник ORM / Hibernate и могу эффективно его использовать, но я считаю, что многие разработчики недооценивают сложность / сложность использования инструментов ORM, таких как Hibernate.
Единственное исключение, которое может заставить меня экспортировать Schema, - это если я пишу одноразовый прототип и не очень хорошо знаю DDL для конкретной базы данных. Но я не сталкивался со многими выброшенными прототипами, которые внезапно не стали постоянными.
Это мои доводы против создания DDL из аннотаций Hibernate. Я надеюсь, что другие присоединятся к их мыслям и опыту.