我目前正在尝试与JPA合作。我情不自禁地觉得我错过了一些东西,或者做错了。到目前为止,这似乎是被迫的。
到目前为止,我认为我知道他们有几种方法可以使用JPA和工具来支持这一点。
这两者似乎都有缺点,并且两者都有好处(就像所有事情一样)。 我的问题是在理想的情况下,JPA的标准工作流程是什么?大多数模式在维护阶段需要更新,特别是在开发阶段,所以如何处理?
答案 0 :(得分:1)
像往常一样,答案取决于......
理想方法(在理想世界中)可能是您的第一选择:使用实用工具(例如使用Hibernate Maven plugin)使用JPA注释和转发工程师数据库工件来维护所有内容。
这取决于对数据库工件的支持级别 - 并非所有内容都属于或适用于注释。这就是为什么我的项目通常对两者都使用并行维护并使用单元测试来保持它们同步。
它还取决于可用资源。如果您有一位负责数据库的专职DBA,那么将维护委托给她是有意义的。
其他考虑因素是在JPA中实际完成了多少数据库开发。是否存在使用相同后端的存储过程或其他非JPA应用程序,或者您只是与其他团队的数据库集成...
答案 1 :(得分:1)
从带注释的实体生成数据库模式并不总是一种好方法。虽然理论上听起来很棒 - 但实际上生成的模式通常不是最优的,也不会满足并经历过DBA。
我在工作流程中遵循的方法是分别创建实体和数据库模式,同时仍然使用非常智能的工具来创建模式 - 像Liquibase这样的数据库无关,支持修订, rollbacks等...或者一个自定义的烘焙迁移工具,它只运行大量优化的特定于db的sql脚本。
这可能听起来不太理想,但我可以保证它可以完成工作并保持与模式相关的代码一致,因为正如格里戈里所指出的那样 - 并非所有与数据库相关的内容都可以从实体生成。 / p> 但是,对于从运行单元和集成测试的测试数据库的实体生成模式,我可以很有用。假设你正在使用说PostgreSQL是生产你可能决定加速运行一些嵌入式内存数据库(如H2)的单元测试,它在测试开始之前从实体创建并自动消失(因为它在内存中) )测试完成后执行。这是一种非常普遍的做法。
答案 2 :(得分:1)
如果这是一个现有的应用程序,我会检查你现有的内容,如果数据库结构复杂,可以看到DDL和DDL显示数据库本身正在进行重要的逻辑,那么你最好使用纯SQL,让DBA维护您的数据结构。当数据库结构已经很复杂并且在那时使用JPA没有商业利益时,JPA并没有真正发挥作用。
需要发生的是迁移到JPA的项目。这有一些好处:
对于正在生成的模式等,实际上可能会发生四种工作流程:
它的网络是你不能只说你在使用JPA而不涉及整个交付团队,这将需要包括DBA愿意放弃对应用团队的数据结构的控制和所有权,但是仍然是设计和评论的一部分。