使用 JPA/ORM 生成数据库模式是个坏主意吗？答案

【问题标题】：Is using JPA/ORM to generate a db schema a bad idea?使用 JPA/ORM 生成数据库模式是个坏主意吗？
【发布时间】：2011-09-30 08:13:52
【问题描述】：

救命！

SO 上another question/answer 的一部分（以及声称相同的其他声明）：

如果您通过 JPA 更新数据库架构（但通常不是一个好习惯）

您真的不应该使用 JPA 实现来生成您的数据库架构吗？

无论如何，我必须自己建模实体和关系。我还需要定义约束，例如 notnull、主键和外键、数据类型和大小。

假设使用中的 JPA 实现在其 DDL 模式创建代码中没有任何缺陷，并且假设我确实正确指定了所有 JPA 约束、关系等，那么 JPA 实现创建的数据库模式应该完全相同- 如果不是更好的话 - 作为我自己手工制作的模式，对吧？

这不包括“特殊情况”，例如（业务逻辑）特定的 INSERT 触发器等，因为这些完全不能由 JPA 实现生成（据我所知，如果我错了）。

您对此有何看法？
我目前首先手工制作我的数据库模式，然后设置 JPA 约束、关系等，并让 JPA 实现也创建一个数据库模式。然后我比较这两个模式，看看我是否正确地完成了设置。这当然意味着我还必须指定与我为我的手工架构所做的相同的列名等。

为了让我的问题更准确；我不会盲目相信 ORM 框架会为我生成模式。我宁愿对架构在我的脑海中的外观有所了解，然后配置框架以匹配它。
我想您只能手动创建更多/最有效的模式，但毕竟我需要（或者更确切地说想要）将它们与 ORM 框架一起使用。因此，虽然我不应该这样做，但无论如何在创建数据库模式时，我都需要牢记 ORM 框架的局限性。

既然我使用 ORM 框架是为了不必关心 RDBMS 的细节，那么让我的应用程序使用 RDBMS 特定的 DDL 创建架构有什么意义？
如果我必须使用一些现有的和外来的模式，我不需要（重新）创建模式，因为我可能无法使用这样的通用工具作为 ORM 框架。

【问题讨论】：

我刚刚注意到我写了这个问题，而不是以 JPA 为中心，但我想它适用于任何 ORM 框架。

标签： java jpa orm db-schema

【解决方案1】：

我通常只让 JPA 最初创建模式。之后，我手动对其进行微调和维护。

我更喜欢手动维护架构有几个原因：

它允许将 cmets 放入 SQL 代码中
它允许为表和列添加 cmets/描述
它允许指定表空间和其他使用 JPA 注释无法实现的东西
它允许在多个 SQL 文件之间拆分架构创建（例如，每个表一个 + 一个用于约束）
它允许我在架构迁移脚本中重用架构创建脚本的某些部分。例如，如果我的应用的第 2 版引入了 3 个新表，我需要一个更改脚本，该脚本可以重用创建三个新表的三个 SQL 文件
我有时需要为序列使用同义词，而不是具体的同义词
它让我可以选择主键约束的名称
可能还有其他一些我忘记的原因

【讨论】：

+1。我想知道使用 sysnonyms（特别是序列）的用例是什么
我遇到过这样一个案例，即在两个不同的架构上同时部署了一个应用程序的两个版本。但是我们希望之后能够合并这两个模式，因此使用序列的同义词来确保两个应用程序使用相同的序列，并且我们不会在两个模式中有重复的 ID。
我不会选择 SQL 中的 cmets 作为参数。无论如何，您需要对 DDL 之外的对象/关系进行一些更一般的文档说明。表空间、查询索引等是一个有效点，我的问题中没有考虑到这一点！最终数据库模式（例如数据库管理员）中的注释和描述也很好。我想知道为什么 ORM 框架不支持这些？例如。使用 cmets 扩展现有的 JPA 注释，以允许自动创建列描述甚至 db 文档 ala javadoc。
我在考虑 cmets，例如“此索引对用例 XYZ 很有用。在版本 3 中添加 foo 列可能很有用”。或“此约束是避免错误 3452 所必需的”。
再想一想，这些点不都是ORM框架的限制吗？毕竟他们应该做肮脏的工作。如果他们不支持（自动）文档（他们的 SQL 结果）或版本控制（他们自己的模式），那对我来说听起来很像一个缺失的功能。 ORM 框架甚至可以根据实际使用情况对模式进行微调。

【解决方案2】：

我通常做相反的事情，即手动创建数据库模式，然后我使用我的 IDE 从中导出 JPA 实体结构。之后，我再次手动优化 JPA 实体。

【讨论】：

还没想到这个。似乎是个好主意，因为这增加了知道在 IDE 上使用哪些注释的负担:)