简而言之，我正在处理一个相对较大的新项目...许多表格，许多关联，继承...（到目前为止，我已经创建了UML和MCD）。
我想知道从这一步开始最好的方法是什么：我应该手动创建数据库，然后使用JPA生成实体，还是先手动创建实体，然后生成我的数据库？什么是最好的方法，这样我就可以避免以后出现更大的问题...
我想知道从这一步开始最好的方法是什么：我应该手动创建数据库，然后使用JPA生成实体，还是先手动创建实体，然后生成我的数据库？什么是最好的方法，这样我就可以避免以后出现更大的问题...
4个回答
2
这要看情况而定 :-).
- 如果您的应用程序“拥有”数据库（是唯一的用户），通常将数据库视为实现细节，并让JPA创建它是有意义的。这样，您就不必操纵SQL，而且数据库始终与JPA所期望的相匹配。这对于像 Essex Boy 的回答所描述的测试场景也非常有用。
- 如果数据库已经存在，或者需要与其他应用程序共享，则您的选择已经做出 - 您必须使用现有的内容（并小心更改）。
- 可能会有外部约束条件限制数据库结构。也许您必须使用存储过程，或使用某些DB命名约定，或者在更新期间使用模式迁移工具强制执行约束。在这种情况下，您将需要详细控制DB结构，这通常意味着您必须使用SQL自己创建它。
因此，请检查您正在操作的约束条件，然后再决定。
- sleske
1
谢谢！我决定按照你的答案从实体生成数据库。 - cimecut
1
我强烈建议您让实体生成表格。
这也有助于测试和开发，例如，您可以使用每个测试构建和拆除的H2数据库。
在项目相当成熟之前，我甚至不会看数据库。
JPA实体可以在没有任何表或列名称的情况下开始生命周期，然后随着项目的进展，可以同意列和表名称，而不会对其余代码产生任何影响。
在最终集成阶段，可以对实体JPA注释进行微小更改，以允许Oracle、DB2等特定数据类型异常。
应用程序应负责其自己的数据库。这对于新项目尤其相关。
这也有助于测试和开发，例如，您可以使用每个测试构建和拆除的H2数据库。
在项目相当成熟之前，我甚至不会看数据库。
JPA实体可以在没有任何表或列名称的情况下开始生命周期，然后随着项目的进展，可以同意列和表名称，而不会对其余代码产生任何影响。
在最终集成阶段，可以对实体JPA注释进行微小更改，以允许Oracle、DB2等特定数据类型异常。
应用程序应负责其自己的数据库。这对于新项目尤其相关。
- Essex Boy
2
"应用程序应该对其自己的数据库负责。"虽然这是一个可行的观点，但并非每个人都同意。长期以来，数据库被认为是多个应用程序互操作的好方法。现在可能正在发生变化，例如微服务应该拥有它们自己的“独立”数据库，但这绝不是每个人都同意的事情。 - sleske
我相信很多人会持不同意见，但这是我的看法。问题暗示着没有现有的数据库。在我看来，存储过程在许多方面都很糟糕。命名约定可以通过JPA注释进行适配。更改应该使用Liquibase而不是SQL。 - Essex Boy
1
生成模式（由ORM层完成）是一种方便的功能，但在生产之前，应该由熟悉数据库的人（DBA）对生成的模式进行验证。即使先创建模式，然后创建正确的ORM映射也是更可靠/高效的方法。
- Kevin Peters
1
没错，我应该在应用程序投入生产之前将创建数据库的代码（我稍后会生成，因为我决定从实体生成数据库）提供给数据库管理员…… 在中大型企业中通常是这样的。 - cimecut
1
从实体或非实体创建表格。永远不要从数据模型创建您的对象模型。始终要从领域分析创建您的对象模型。JPA不是数据操作工具，而是对象操作工具。
如果您无法控制数据库模式，则只能希望它支持对象模型，并找出如何将您的对象模型映射到关系模型。这就是为什么它被称为对象到关系映射（ORM），而不是关系到对象映射。
永远不要让数据模型驱动您的对象模型。
- Lew Bloch
3
我从未这样想过！这实际上非常有道理。如果对每个用户（包括初学者）都有帮助，以帮助未来的SO访问者，我会接受这个答案。 - cimecut
“从来没有”是一个强烈的说法...但我赞同这种精神：不要让现有的数据库模式束缚你的思维。 - sleske
如果你能想到一个反例... - Lew Bloch
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接