我目前正在尝试与 JPA 合作。我情不自禁地觉得自己错过了一些东西或者以错误的方式做事。到目前为止，这似乎只是被迫的。
我想到目前为止我所知道的是，有几种使用 JPA 的方法和支持这一点的工具。
- 您可以使用注释在 Java 中完成所有操作，并让 JPA（无论您决定使用什么实现）创建您的模式并在发生更改时更新它。
- 您可以使用工具对数据库进行逆向工程并为您生成实体类。当架构更新时，您必须重新生成这些类，或手动更新它们。
似乎两者都有缺点，也都有优点（就像所有事情一样）。 我的问题是，在理想情况下，JPA 的标准工作流程是什么？ 大多数模式在维护阶段，特别是在开发阶段都需要更新，那么如何处理呢？
I am currently trying to wrap my head around working with JPA. I can't help but feel like I am missing something or doing it the wrong way. It just seems forced so far.
What I think I know so far is that their are couple of ways to work with JPA and tools to support this.
- You can do everything in Java using annotations, and let JPA (whatever implementation you decide to use) create your schema and update it when changes are made.
- You can use a tool to reverse engineer you database and generate the entity classes for you. When the schema is updated you have to regenerate these classes, or manually update them.
There seems to be drawbacks to both, and benefits to both (as with all things). My question is in an ideal situation what is the standard workflow with JPA? Most schemas will require updates during the maintenance phase and especially during the development phase, so how is this handled?
发布评论
评论（3）
从带注释的实体生成数据库模式并不总是一个好方法。尽管理论上听起来不错，但实际上生成的模式通常不是最佳的，并且无法满足经验丰富的 DBA。
我在工作流程中遵循的方法是分别创建实体和数据库模式，同时仍然使用非常智能的工具来创建模式 - 类似于 Liquibase，与数据库无关，支持修订、回滚等...或者是一个自定义烘焙迁移工具，只需运行高度优化的数据库特定 SQL 脚本。
这对您来说可能听起来不太理想，但我可以保证它可以完成工作并保持与模式相关的代码一致，因为正如 grigory 指出的那样 - 无论如何，并不是与数据库相关的所有内容都可以从实体生成。
但是，我可以从正在运行单元和集成测试的测试数据库的实体生成模式。假设你使用的是 PostgreSQL 是生产环境，你可能会决定加快单元测试的速度，运行一些嵌入式内存数据库，比如 H2，它是在测试开始之前从实体创建的，并自动消失（因为它是在内存中的） ）测试完成执行后。这是一种非常常见的做法。
It's not always a good approach to generate the DB schema from the annotated entities. Although in theory it sounds great - in practice often the generated schema is not optimal and would not satisfy and experienced DBA.
The approach that I follow in my workflow is to create the entities and db schema separately, while still using a pretty intelligent tool for the schema creating - either something like Liquibase, that is database agnostic, supports revisions, rollbacks, etc... or a custom baked migration tool that simply runs heavily optimized db specific sql scripts.
It probably sounds to you less than ideal, but I can assure it gets the jobs done and keep your schema related code consistent since, as grigory pointed out - not everything related to the database can be generated from the entities anyways.
I can, however, be useful to generate the schema from the entities for the test database against which unit and integration tests are being run. Assuming you're using say PostgreSQL is production you might decide to speed things up for the unit tests running some embedded in-memory database like H2 which gets created from the entities before the tests are started and disappears automatically(since it was in-memory) after the tests finish executing. This is a very common practice.
像往常一样，答案是这取决于...
理想的方法（在理想的世界中）可能是您的第一个选择：使用 JPA 注释维护所有内容，并使用实用工具（例如使用 Hibernate Maven 插件）。
这取决于对数据库工件的支持级别 - 并非所有内容都属于或适合注释。这就是为什么我的项目通常对两者使用并行维护，并使用单元测试来保持它们同步。
它还取决于可用的资源。如果您有一位专门的 DBA 负责您的数据库，那么将维护工作委托给她是有意义的。
其他考虑因素是有多少数据库开发实际上是在 JPA 中完成的。是否还有使用相同后端的存储过程或其他非 JPA 应用程序，或者您可能只是与其他团队的数据库集成......
As usual the answer is it depends...
Ideal approach (in ideal world) would probably be your 1st option: maintain everything using JPA annotations and forward engineer database artifacts using utility tool (e.g. use Hibernate Maven plugin).
It depends on the level of support for your database artifacts - not everything either belongs or suitable for annotations. That is why my projects usually use parallel maintenance for both and using unit tests to keep them in sync.
It also depends on resources available. If you have a dedicated DBA who is responsible for your database then delegating maintenance to her would make sense.
Other consideration is how much database development is really done in JPA. Are there also stored procedures or other non-JPA applications that use the same back-end, or maybe you just integrate with other team's database...
如果这是一个现有的应用程序，我会检查您现有的应用程序，如果数据库结构复杂（如 DDL 所示）并且 DDL 显示正在数据库本身上完成重要逻辑，那么您最好使用纯 SQL 和让 DBA 维护您的数据结构。当数据库结构已经很复杂并且此时使用 JPA 没有任何商业利益时，JPA 就不太适合了。
需要做的是一个迁移到 JPA 的项目。这样做有几个优点：
至于生成的模式等，实际上可能会发生四种工作流程：
最终结果是，您不能只是说您正在使用 JPA，而无需整个交付团队的参与，整个交付团队必须包括 DBA，他们愿意将数据结构的控制权和所有权交给应用程序团队，但仍是其中的一部分的设计和评论。
If this is an existing application, I would check what you have existing, if the database structure complex as can be seen with the DDL and the DDL shows significant logic is being done on the database itself, then you are better off using plain SQLs and let the DBA maintain your data structures. JPA does not really lend well when the database structures are already complicated and there is no business benefit to use JPA at that point.
What needs to happen is a project to migrate to JPA. There are a few advantages to that:
As for schemas being generated and such, there are actually four workflows that can occur:
The net of it is you can't just say you're using JPA without involving the whole delivery team which will have to include the DBA willing to relinquish control and ownership of the structure of the data to the application team, but still be part of the design and reviews.