Java Hibernate/JPA DB模式生成最佳实践

我只是想听听Hibernate专家对基于Hibernate/JPA项目的DB模式生成最佳实践的看法。特别是：

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

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

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

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

在产品中，最好是手动生成并检查模式

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

---

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

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

对于在生产环境中部署-一个明显的提示-首先确保在测试环境中生成的所有内容都正常，然后手动在生产环境中部署。

，因为：

同一数据库可由不同的应用程序使用，而不是所有应用程序 他们将使用hibernate甚至java。数据库架构应该 不是由ORM决定的，它应该围绕数据和 业务需求

hibernate选择的数据类型可能不适合应用程序

如前一评论所述，如果数据丢失是不可接受的，对实体的更改将需要人工干预

例如附加属性（通用术语，而不是java 连接表上的属性）在RDBMS中工作得非常好，但是 在ORM中使用有点复杂和低效。这样做 从ORM->RDBMS映射可能会创建不可用的表 有效率的理论上，可以构建完全相同的连接 表使用hibernate生成的代码，但需要一些 书写实体时要特别小心

---

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

正如Bozhidar所说，不要让Hibernate创建和更新数据库模式。 让您的应用程序创建和更新数据库架构。

---

对于java来说，最好的工具是。您需要使用描述数据库模式的DDL语句创建一个或多个SQL文件。然后通过Flyway执行这些SQL文件。有关更多信息，请查看。

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

---

就个人而言，我更倾向于后者，参考单一责任原则（SRP），我更喜欢由DB专家处理DB，由应用程序专家处理应用程序，而不是由应用程序处理DB。此外，我认为，一开始走太多的捷径会很好，但随着事情的发展，会产生难以管理的问题。

我想，这么大的问题很大程度上取决于您的项目以及它是否可以接受：-集中部署（例如，基于JEE的部署）vs client server like-允许在任何时候使用多个客户端版本（=>关注数据库列删除、完整性约束等）-热部署vs stop应用程序已被接受-…但假设您必须以导致创建新表的方式更改生产环境中的实体关系，一些曾经是旧表的一部分的数据必须插入到这些新表中。例如，假设您有一个名为Person的实体，其中包含地址信息字段，现在您希望创建一个单独的实体来保存地址信息。这将导致创建一个新表，您必须将地址数据从person表迁移到此新表。但是Hibernate不能自动做到这一点……我个人强烈反对这种方法。尤其是在谈到生产时。对我来说，对过程的控制不够，这里有太多的魔力。Liquibase为您解决了“单独跟踪DDL脚本-即管理其修订并将其与实体更改同步（反之亦然）”的问题。您已经清楚地了解了对db scheme应用了哪些更改。通过自动生成表，您根本没有任何版本控制。这个