Hibernate / JPA DB Schema Generation最佳实践

时间:2010-04-06 14:36:50

标签: java hibernate jpa

我只想听听Hibernate专家关于基于Hibernate / JPA项目的数据库模式生成最佳实践的意见。特别是:

  1. 项目刚刚启动时使用什么策略?是否建议让Hibernate在此阶段自动生成模式,还是最好从项目的最早阶段手动创建数据库表?

  2. 假设在整个项目中使用Hibernate生成模式,是否最好在系统投入生产之前禁用自动模式生成并手动创建数据库模式?

  3. 系统投入生产后,维护实体类和数据库架构的最佳做法是什么(例如添加/重命名/更新列,重命名表等)?

5 个答案:

答案 0 :(得分:35)

  1. 始终建议手动生成架构,最好是通过支持数据库架构修订的工具,例如伟大的Liquibase。从实体生成模式在理论上是很好的,但在实践中很脆弱并且从长远来看会导致很多问题(相信我)。

  2. 在制作中,最好手动生成并查看架构。

  3. 您对实体进行更新并创建匹配的更新脚本(修订版)以更新数据库架构以反映实体更改。您可以创建一个自定义解决方案(我写了一些)或使用更流行的东西,如liquibase(它甚至支持架构更改回滚)。如果您正在使用maven或ant等构建工具 - 建议将db schema update util插入构建过程,以便新构建与架构保持同步。

答案 1 :(得分:13)

虽然有争议,但我会说所有3个问题的答案是:让hibernate自动生成模式中的表。

到目前为止,我没有遇到任何问题。您可能需要不时手动清理某些字段,但与单独跟踪DDL脚本相比,这并不令人头疼 - 即管理其修订并将其与实体更改同步(反之亦然)

对于生产部署 - 一个明显的提示 - 首先确保在测试环境中生成所有内容,然后在生产中进行部署。

答案 2 :(得分:5)

手动,因为:

  1. 相同的数据库可能由不同的应用程序使用,而不是全部 他们将使用hibernate甚至java。数据库架构应该 不是由ORM决定的,它应该围绕数据而设计 业务要求。
  2. hibernate选择的数据类型可能不适合应用程序。
  3. 如前面的评论中所述,如果数据丢失不可接受,对实体的更改将需要手动干预。
  4. 诸如附加属性之类的东西(通用术语而不是java     连接表上的属性)在RDBMS中运行得非常好但是         在ORM中使用有点复杂和低效。做这样的         从ORM映射 - > RDBMS可能会创建不是的表         高效。理论上,可以构建完全相同的连接         表使用hibernate生成的代码,但它需要一些         在撰写实体时要特别小心。
  5. 我会将自动生成用于通过相同ORM层访问的独立应用程序或数据库,以及是否需要将应用程序移植到不同的数据库。通过不要求编写和维护DB供应商特定的DDL脚本,可以节省大量时间。

答案 3 :(得分:2)

像Bozhidar所说,不要让Hibernate创建和更新数据库架构。 让您的应用程序创建和更新数据库模式。 对于java,执行此操作的最佳工具是Flyway。您需要使用描述数据库模式的DDL语句创建一个或多个SQL文件。然后由Flyway执行这些SQL文件。有关更多信息,请查看Flyway的网站。

答案 4 :(得分:1)

我相信,如果您对代码优先或数据库优先方法更加轻松,那么正在讨论或论证的内容也应与之相关。

就个人而言,我更倾向于选择后者,并且参考单一责任原则(SRP),我更愿意让数据库专家处理数据库和处理应用程序的应用程序专家,而不是让应用程序处理数据库。另外,我认为采用太多的快捷方式一开始就能很好地工作,但随着事情的发展和发展,会产生无法解决的问题。

相关问题