JPA：我应该从表中生成实体，还是从实体中生成表？ [关闭]答案

【问题标题】：JPA: should I generate entities from tables, or generate tables from entities? [closed]JPA：我应该从表中生成实体，还是从实体中生成表？ [关闭]
【发布时间】：2017-08-06 01:36:12
【问题描述】：

简而言之，我正在开发一个相对较大的新项目......许多表、许多关联、继承......（到目前为止，我已经创建了 UML 和 MCD）

我想知道从这一步开始的最佳方法是什么：我应该手动创建数据库然后使用 JPA 生成实体，还是应该先手动创建实体然后生成我的数据库？最好的方法是什么，这样我以后可以避免更大的问题......

【问题讨论】：

liquibase 脚本生成数据库，然后从数据库生成实体
我决定从实体生成数据库，这对我来说更有意义，因为我没有使用任何存储过程或类似的东西......除了我没有创建表还为我的应用程序。请参阅接受的答案以获取有关我为什么决定使用此方法的更多信息。谢谢@ByeBye
我不会让 JPA 管理我的数据库结构，因为它的所有标准选项都会破坏您的数据。是从表中生成实体还是手动生成实体，这是一个偏好问题。

标签： java mysql jpa entities

【解决方案1】：

这取决于:-)。

如果您的应用程序“拥有”数据库（是唯一的用户），通常将数据库视为实现细节并让 JPA 创建它是有意义的。这样，您就不必弄乱 SQL，并且数据库始终与 JPA 所期望的相匹配。如 Essex Boy 的回答所述，这对于测试等场景也很有用。
如果数据库已经存在，或者打算与其他应用程序共享，那么您已经做出了选择 - 您必须使用现有的数据库（并小心更改）。
数据库结构可能存在外部约束。也许您必须使用存储过程，或者使用某些数据库命名约定，或者您在更新期间使用一种工具进行模式迁移，从而施加约束。在这种情况下，您需要对数据库结构进行详细控制，这通常意味着您必须使用 SQL 自己创建它。

因此，请检查您正在处理的约束条件，然后再决定。

【讨论】：

谢谢！我决定根据您的回答从实体生成数据库。

【解决方案2】：

我强烈建议您让实体生成表格。

这也将有助于测试和开发，例如，您可以使用为每次测试构建和拆除的 H2 数据库。

在项目相当先进之前，我什至不会查看数据库。

JPA 实体可以在没有任何表或列名的情况下开始生命，然后随着项目的推进，列名和表名可以在不影响其余代码的情况下达成一致。

在最后的集成阶段，可以对实体 JPA 注释进行细微更改，以允许 Oracle、DB2 等的特定数据类型异常。

应用程序应该对自己的数据库负责。这对于新项目尤其重要。

【讨论】：

"应用程序应该对自己的数据库负责。"虽然这是一个可行的观点，但并不是每个人都同意这一点。长期以来，数据库被认为是多个应用程序互操作的好方法。这现在可能正在改变，例如微服务应该有自己的“自己的”数据库，但这绝不是每个人都同意的。
我相信很多人会不同意，这是我的观点。这个问题意味着没有现有的数据库。存储过程在很多方面都很糟糕（在我看来），命名约定可以通过 JPA 注释来适应。应该使用 Liquibase 而不是 SQL 进行更改。

【解决方案3】：

模式生成（由 ORM 层完成）是一种方便的功能，但生成的模式在任何情况下都应由熟悉数据库的人员（DBA）在其投入生产之前进行验证。甚至首先创建架构，然后创建正确的 ORM 映射也是更高效/更可靠的方式。

【讨论】：

没错，我应该在应用程序投入生产之前将数据库创建代码（我将在稍后生成，因为我决定从实体生成数据库）提供给 DBA...通常大中型公司采用这种方式

【解决方案4】：

来自实体的表或两者都不是。永远不要从数据模型创建您的对象模型。始终从域分析中创建对象模型。 JPA 不是数据操作工具，它是对象操作工具。

如果您无法控制数据库架构，您只需要希望它支持对象模型，并弄清楚如何将您的对象模型映射到关系模型。这就是为什么它被称为对象到关系映射 (ORM)，而不是关系到对象映射。

永远不要让数据模型驱动您的对象模型。

【讨论】：

我从来没有这样想过！这实际上是有道理的，很多。如果它对每个用户（也是初学者）都有意义以帮助未来的 SO 访问者，我会接受这个答案。
“从不”是一个强有力的声明......但我同意这种精神：不要让你的想法被现有的数据库模式束缚。
如果你能想到一个反例......