JPA，从实体到数据库模式开始

使用JPA时哪个更好，特别是在启动新项目时？从设计实体开始，然后让JPA生成数据库或者从数据库模式开始，让工具生成实体类？

我是一家小公司的一部分。我是软件开发人员和DBA。我有完全的应用程序和数据库设计自由

我刚刚开始这个项目

如果要设计数据库，请从架构开始。如果要编写软件，请从实体开始。 ORM的目的是让你考虑一个对象模型，而不必担心存储它的数据库，所以这种类型的问题实际上通过暗示领域之间的交叉来混淆这个问题。您是软件开发人员还是DBA？这比你使用JPA的事实要多，这将决定你的正确答案。

嗯 – 不是吗？ JPA的强大之处在于您无需从另一个生成一个！如果已经有实体或数据库模式的生成可能是一个很好的起点 ; 但生成的东西不是你想要长期使用的东西。

您不能简单地设计映射的一侧而不考虑另一侧。如果要与其他应用程序共享数据库，则需要对数据库模式给予更多权重。如果您的应用程序具有复杂的模型，您将首先关注对象模型，允许它由您在开发应用程序时发现的用例驱动。

我倾向于首先从对象模型开始（即使没有支持数据库也可以启动），因为这样我可以更早地看到应用程序，并了解我们真正想要构建的内容。但是与数据库的集成必须提前而不是更晚; 因为它的约束会很快强加在你的对象模型上。 🙂

这取决于一个人的需求。通常在产品开发环境中，有不同的团队从事数据库设计，界面设计和实现。因此，在这种情况下，除了从已经存在的数据库设计生成JPA实体之外别无选择。其次，如果你从头开始并且你知道你到底做了什么，那么你可以开始编写自己的实体（java类），然后从中生成数据库。

最好去数据库方案。因为JPA生成的数据库中没有一些function。在JPA中，我们无法为列提供默认值。在此处查看JPA中的允许属性。

由你决定。是自上而下还是自下而上的方法。如果此架构专用于您的应用程序，请查看您的团队成员和分析师如何理解ORM或DB。根据我的经验，分析师可以更好地理解表格。但如果他们很好地讨论类或UML图表，请使用JPA。另外，请考虑您的DBA和构建工程师的观点。

如果您具有完全的灵活性，并且不限于数据库模式，并且希望在Java应用程序中使用干净的对象模型，那么首先从模型开始，然后从模型生成模式。这也允许您从干净模型生成干净的JSON表示，以使用像Jackson（或GSON）这样的技术作为对象的在线格式。

首先执行DB Schema并从中反向工程模型类将导致渗入模型类的关系概念导致模型不良（污染）。

总之，除非你的双手被束缚并且你必须映射到一些现有的架构，否则先做模型。