Будьте в спящем режиме: hbm2ddl.auto=update в производстве?

Я соглашаюсь с Vladimir. Администраторы в моей компании определенно не ценили бы его, если бы я даже предложил такой курс.

Далее, создавая сценарий SQL в земельном участке слепого доверия В спящем режиме, дает Вам возможность удалить поля, которые больше не используются. Будьте в спящем режиме не делает этого.

И я нахожу, что сравнение производственной схемы с новой схемой дает Вам еще лучшее понимание wat, который Вы изменили в модели данных. Вы знаете, конечно, потому что Вы сделали его, но теперь Вы видите все изменения сразу. Даже те, которые заставляют Вас пойти как "Какого черта?!".

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

Мы делаем это в производстве, хотя с приложением это не в жестком реальном времени и без высокооплачиваемого DBAs в штате. Это всего один меньше ручного процесса, это подвергается человеческой ошибке - приложение может обнаружить различие и сделать правильную вещь, плюс Вы, по-видимому, протестировали его в различной разработке и тестовых средах.

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

Я голосовал бы нет. Будьте в спящем режиме, кажется, не понимает, когда типы данных для столбцов изменились. Примеры (использующий MySQL):

String with @Column(length=50)  ==> varchar(50)
changed to
String with @Column(length=100) ==> still varchar(50), not changed to varchar(100)

@Temporal(TemporalType.TIMESTAMP,TIME,DATE) will not update the DB columns if changed

существуют, вероятно, другие примеры также, такие как увеличивание длины столбца String более чем 255 и наблюдение, что он преобразовывает в текст, mediumtext, и т.д. и т.д.

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

Миграционный маршрут является хорошим вариантом иметь дело с этой проблемой:

http://flywaydb.org

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

• Обычно корпоративные приложения в крупных организациях работают с ограниченными привилегиями.

• Имя пользователя базы данных может не иметь прав DDL для добавления столбцов, которые требуются для hbm2ddl.auto = update .

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

Сохранение всей вашей настойчивости в отображениях (или аннотациях) Hibernate - очень хороший способ держать эволюцию схемы под контролем.

Следует учитывать, что при эволюции схемы необходимо учитывать несколько аспектов:

1. эволюция схемы базы данных при добавлении дополнительных столбцов и таблиц

2. удалении старых столбцов, таблиц и Relations

3. заполнение новых столбцов значениями по умолчанию

Инструменты Hibernate особенно важны в случае (как в моем опыте) у вас есть разные версии одного и того же приложения во многих разных типах баз данных.

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

Я бы сделал следующее: действительно использовал возможности инструментов Hibernate для обновления схемы, но вы должны добавить наряду с этим некоторые данные и обратный вызов для обслуживания схемы, например, для заполнения значений по умолчанию, удаления больше не используемых столбцов и т. Д. Таким образом, вы получаете преимущества (сценарии обновления схемы, не зависящие от базы данных и избежание дублирования кодирования обновлений, в постоянстве и в сценариях), но вы также охватываете все аспекты операции.

Так, например, если обновление версии состоит просто в добавлении свойства, оценивающего varchar (следовательно, столбца), которое по умолчанию может иметь значение null, с автоматическим обновлением все будет сделано. Там, где требуется больше сложности, потребуется больше работы.

Предполагается, что приложение при обновлении способно обновлять свою схему (это можно сделать), что также означает, что у него должны быть права пользователя для этого в схеме. Если политика клиента предотвращает это (вероятно, в случае с Lizard Brain), вам придется предоставить скрипты, специфичные для базы данных.