查看LiquiBase XML以保持更新的更新日志。直到今年我才开始使用它，但我发现它非常容易学习，并且使DB修订控制/迁移/变更管理非常简单。我在一个Groovy/Grails项目中工作，Grails在其所有ORM(称为“GORM”)的底层使用Hibernate。我们使用Liquibase来管理所有SQL模式的更改，随着应用程序的新功能的发展，我们经常这样做。

Basically, you keep an XML file of changesets that you continue to add to as your application evolves. This file is kept in git (or whatever you are using) with the rest of your project. When your app is deployed, Liquibase checks it's changelog table in the DB you are connecting to so it will know what has already been applied, then it intelligently just applies whatever changesets have not been applied yet from the file. It works absolutely great in practice, and if you use it for all your schema changes, then you can be 100% confident that code you checkout and deploy will always be able to connect to a fully compatible database schema.

最棒的是，我可以在我的笔记本电脑上使用一个完全空白的mysql数据库，启动应用程序，模式就马上为我设置好了。通过首先将模式更改应用到本地开发或登台db，还可以很容易地测试模式更改。

开始使用它的最简单方法可能是使用现有的DB，然后使用Liquibase生成一个初始的baseline.xml文件。然后在将来，您可以添加到它，并让liquibase接管管理模式更改。

http://www.liquibase.org/

通常，大型组织中的企业应用程序以较少的权限运行。 数据库用户名可能没有DDL权限，不能添加hbm2ddl的列。汽车=更新要求。

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

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

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

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

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

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

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

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

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

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

我不会冒这个险，因为你可能会丢失本该保存的数据。hbm2ddl。Auto =update纯粹是一种保持开发数据库最新的简单方法。

不，永远不要这么做。Hibernate不处理数据迁移。是的，它将使您的模式看起来正确，但它不能确保有价值的生产数据不会在过程中丢失。