我们在一个已经在生产环境中运行了几个月的项目中这样做，到目前为止从来没有遇到过问题。记住这道菜需要的两种原料:

Design your object model with a backwards-compatibility approach, that is deprecate objects and attributes rather than removing/altering them. This means that if you need to change the name of an object or attribute, leave the old one as is, add the new one and write some kind of migration script. If you need to change an association between objects, if you already are in production, this means that your design was wrong in the first place, so try to think of a new way of expressing the new relationship, without affecting old data. Always backup the database prior to deployment.

我的感觉是——在阅读了这篇文章之后——参与讨论的90%的人一想到在生产环境中使用这样的自动化就感到恐惧。有些人把球扔向DBA。花点时间考虑一下，并不是所有的生产环境都会提供DBA，也不是很多开发团队能够负担得起(至少对于中等规模的项目)。所以，如果我们谈论的是每个人都必须做所有事情的团队，球就在他们身上。

既然如此，为什么不试着两全其美呢?像这样的工具可以提供帮助，通过仔细的设计和计划，可以在许多情况下提供帮助。相信我，最初可能很难说服管理人员，但如果他们知道球不在他们手中，他们就会喜欢它。

就我个人而言，我永远不会回到手工编写脚本来扩展任何类型的模式，但这只是我的观点。在最近开始采用NoSQL无模式数据库之后，我可以看到，不久之后，所有这些基于模式的操作都将成为过去，所以你最好开始改变你的观点，展望未来。

我们在一个已经在生产环境中运行了几个月的项目中这样做，到目前为止从来没有遇到过问题。记住这道菜需要的两种原料:

Design your object model with a backwards-compatibility approach, that is deprecate objects and attributes rather than removing/altering them. This means that if you need to change the name of an object or attribute, leave the old one as is, add the new one and write some kind of migration script. If you need to change an association between objects, if you already are in production, this means that your design was wrong in the first place, so try to think of a new way of expressing the new relationship, without affecting old data. Always backup the database prior to deployment.

我的感觉是——在阅读了这篇文章之后——参与讨论的90%的人一想到在生产环境中使用这样的自动化就感到恐惧。有些人把球扔向DBA。花点时间考虑一下，并不是所有的生产环境都会提供DBA，也不是很多开发团队能够负担得起(至少对于中等规模的项目)。所以，如果我们谈论的是每个人都必须做所有事情的团队，球就在他们身上。

既然如此，为什么不试着两全其美呢?像这样的工具可以提供帮助，通过仔细的设计和计划，可以在许多情况下提供帮助。相信我，最初可能很难说服管理人员，但如果他们知道球不在他们手中，他们就会喜欢它。

就我个人而言，我永远不会回到手工编写脚本来扩展任何类型的模式，但这只是我的观点。在最近开始采用NoSQL无模式数据库之后，我可以看到，不久之后，所有这些基于模式的操作都将成为过去，所以你最好开始改变你的观点，展望未来。

我会投反对票。当列的数据类型发生变化时，Hibernate似乎无法理解。示例(使用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等等。

当然，我不认为真的有一种方法可以在不创建新列、复制数据和删除旧列的情况下“转换数据类型”。但是一旦你的数据库中有不能反映当前Hibernate映射的列，你就非常危险了……

Flyway是解决这个问题的一个很好的选择:

http://flywaydb.org

在我的情况下(Hibernate 3.5.2, Postgresql, Ubuntu)，设置Hibernate .hbm2ddl。Auto =update仅创建新表，并在已有的表中创建新列。 它既不删除表，也不删除列，也不更改列。它可以被称为一个安全的选择，但有点像hibernate.hbm2ddl。Auto =create_tables add_columns更清楚。

使用hbm2ddl不是一个好主意。汽车生产。

管理数据库模式的唯一方法是使用增量迁移脚本，因为:

脚本将与你的代码库一起驻留在VCS中。签出分支时，从头重新创建整个模式。 增量脚本在应用到生产环境之前可以在QA服务器上进行测试 不需要手动干预，因为脚本可以通过Flyway运行，因此它减少了与手动运行脚本相关的人为错误的可能性。

甚至Hibernate用户指南也建议您避免在生产环境中使用hbm2ddl工具。

应用程序的模式可能会随着时间而变化;如果您有多个安装，可能是不同的版本，您应该有某种方法来确保您的应用程序、某种工具或脚本能够逐步将模式和数据从一个版本迁移到下一个版本。

将所有持久性放在Hibernate映射(或注释)中是控制模式演变的一种非常好的方法。

您应该考虑模式演化有几个方面需要考虑:

数据库模式的演变 添加更多的列和表 删除旧的列，表和 关系 用默认值填充新列

Hibernate工具非常重要，特别是当你在许多不同类型的数据库上有相同应用程序的不同版本时(就像我的经验一样)。

第3点在使用Hibernate时非常敏感，例如在引入一个新的布尔值属性或数值属性时，如果Hibernate在这些列中发现任何空值，则会引发异常。

所以我要做的是:确实使用Hibernate工具的模式更新功能，但必须在它旁边添加一些数据和模式维护回调，比如填充默认值，删除不再使用的列，等等。通过这种方式，您获得了优势(独立于数据库的模式更新脚本和避免在持久性和脚本中对更新进行重复编码)，但也涵盖了操作的所有方面。

因此，例如，如果版本更新只是添加一个varchar值属性(即列)，它可能默认为null，那么使用自动更新就可以完成。在需要更复杂的地方，就需要做更多的工作。

这是假设更新时的应用程序能够更新其模式(这是可以做到的)，这也意味着它必须拥有对模式进行更新的用户权限。如果客户的策略阻止了这一点(可能是Lizard Brain的情况)，您将不得不提供特定于数据库的脚本。