java Hibernate/JPA DB Schema 生成最佳实践

Hibernate/JPA DB Schema Generation Best Practices

提问by Behrang Saeedzadeh

I just wanted to hear the opinion of Hibernate experts about DB schema generation best practices for Hibernate/JPA based projects. Especially:

我只是想听听 Hibernate 专家对基于 Hibernate/JPA 的项目的 DB 模式生成最佳实践的意见。尤其：

1. What strategy to use when the project has just started? Is it recommended to let Hibernate automatically generate the schema in this phase or is it better to create the database tables manually from earliest phases of the project?

2. Pretending that throughout the project the schema was being generated using Hibernate, is it better to disable automatic schema generation and manually create the database schema just before the system is released into production?

3. And after the system has been released into production, what is the best practice for maintaining the entity classes and the DB schema (e.g. adding/renaming/updating columns, renaming tables, etc.)?

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

2. 假设在整个项目中使用 Hibernate 生成模式，在系统发布到生产之前禁用自动模式生成并手动创建数据库模式是否更好？

3. 在系统投入生产后，维护实体类和数据库模式的最佳实践是什么（例如添加/重命名/更新列、重命名表等）？

采纳答案by Bozhidar Batsov

1. It's always recommended to generate the schema manually, preferably by a tool supporting database schema revisions, such as the great Liquibase. Generating the schema from the entities is great in theory, but were fragile in practice and causes lots of problems in the long run(trust me on this).

2. In productions it's always best to have manually generated and review the schema.

3. You make an update to an entity and create a matching update script(revision) to update your database schema to reflect the entity change. You can create a custom solution(I've written a few) or use something more popular like liquibase(it even supports schema changes rollbacks). If you're using a build tool such as maven or ant - it's recommend to plug the db schema update util into the build process so that fresh builds stay in sync with the schema.

1. 始终建议手动生成模式，最好使用支持数据库模式修订的工具，例如伟大的Liquibase。从实体生成模式在理论上很好，但在实践中很脆弱，从长远来看会导致很多问题（相信我）。

2. 在生产中，最好手动生成和检查模式。

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

回答by Bozho

Although disputable, I'd say that the answer to all 3 questions is: let hibernate automatically generate the tables in the schema.

尽管存在争议，但我认为所有 3 个问题的答案都是：让 hibernate 自动生成模式中的表。

I haven't had any problems with that so far. You might need to clean some field up manually from time to time, but this is no headache compared to separately keeping track of DDL scripts - i.e. managing their revisions and synchronizing them with entity changes (and vice-versa)

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

For deploying on production - an obvious tip - first make sure everything is generated OK on the test environment and then deploy on production.

对于在生产中部署 - 一个明显的提示 - 首先确保在测试环境中生成的一切正常，然后在生产中部署。

回答by Dojo

Manually, because:

手动，因为：

1. Same database may be used by different applications and not all of them would be using hibernate or even java. Database schema should not be dictated by ORM, it should be designed around the data and business requirements.
2. The datatypes chosen by hibernate might not be best suited for the application.
3. As mentioned in an earlier comment, changes to the entities would require manual intervention if data loss is not acceptable.
4. Things such as additional properties (generic term not java properties) on join tables work wonderfully in RDBMS but are somewhat complex and inefficient to use in an ORM. Doing such a mapping from ORM -> RDBMS might create tables that are not efficient. In theory, it is possible to build the exact same join table using hibernate generated code, but it would require some special care while writing the Entities.

1. 不同的应用程序可能会使用相同的数据库，并不是所有的应用程序都会使用 hibernate 甚至 java。数据库架构不应该由 ORM 决定，它应该围绕数据和业务需求进行设计。
2. Hibernate 选择的数据类型可能并不最适合应用程序。
3. 正如之前的评论中提到的，如果数据丢失是不可接受的，那么对实体的更改将需要手动干预。
4. 诸如连接表上的附加属性（通用术语不是 java 属性）之类的东西在 RDBMS 中工作得很好，但在 ORM 中使用起来有些复杂且效率低下。从 ORM -> RDBMS 执行此类映射可能会创建效率不高的表。理论上，可以使用休眠生成的代码构建完全相同的连接表，但是在编写实体时需要特别小心。

I would use automatic generation for standalone applications or databases that are accessed via the same ORM layer and also if the app needs to be ported to different databases. It would save lot of time in by not requiring one to write and maintain DB vendor specific DDL scripts.

对于通过同一 ORM 层访问的独立应用程序或数据库，以及如果应用程序需要移植到不同的数据库，我会使用自动生成。由于不需要编写和维护数据库供应商特定的 DDL 脚本，因此可以节省大量时间。

回答by Cengiz

Like Bozhidar said, don′t let Hibernate create&update the database schema. Let your application create and update the database schema. For java the best tool to do this is Flyway. You need to create one or more SQL files with DDL statements which are describing your database schema. These SQL files are then executed by Flyway. For more information look at the site of Flyway.

正如 Bozhidar 所说，不要让 Hibernate 创建和更新数据库模式。让您的应用程序创建和更新数据库架构。对于 Java，最好的工具是Flyway。您需要使用描述您的数据库架构的 DDL 语句创建一个或多个 SQL 文件。这些 SQL 文件随后由 Flyway 执行。有关更多信息，请查看Flyway站点。

回答by Ceddaerrix

I believe that a lot of what is being discussed or argued here should also be related to if you are more confortable with the code-first or the database-first approach.

我相信这里讨论或争论的很多内容也应该与您是否更喜欢代码优先或数据库优先方法有关。

Personally, I am more intended to go for latter and, making a reference to Single Responsibility Principle (SRP), I prefer having DB specialist handling the DB and an application specialist handling the application, than having the application handling the DB. Additionally, I am of the opinion that taking too many shortcuts will work fine at the beginning but create unmanageable problems as things grow/evolve.

就我个人而言，我更倾向于选择后者，并且参考单一职责原则 (SRP)，我更喜欢让 DB 专家处理 DB 和应用程序专家处理应用程序，而不是让应用程序处理 DB。此外，我认为走太多捷径在开始时会很好，但随着事情的发展/发展会产生无法管理的问题。