我在我的域模型中使用Hibernate和Spring Data JPA特性，并使用它们创建实体、关系（@OneToMany、@ManyToOne等）、数据库对象（sequence、index等）。
另一方面，我也喜欢Flyway，并将其用于数据库迁移，有时用于数据库对象创建。
到了这一步，我觉得我做错了什么或者说是多余的，您能不能就以下问题逐一澄清一下？
**1-**假设我们在Sping Boot 应用程序中使用Hibernate/Spring Data JPA和Flyway，并使用@Entity、@OneToMany、@ManyToOne等注解实现实体之间所有必要的关系。那么，我们应该通过注解还是SQL脚本（不是自动生成的脚本），还是两者同时创建数据库对象，例如序列、表索引、约束？
**2-**据我所知，当我们在应用程序属性中设置ddl-auto: none时，JPA对创建数据库等没有任何影响。在这种情况下，使用一些注解（如索引、序列等）有意义吗？当然Flyway数据库init迁移脚本是基于一些注解生成的，但我不确定应该使用注解定义哪些数据库对象，等等，除了实体关系之外。
1条答案
按热度按时间mm5n2pyu1#
以下是我使用过几次的策略，包括在一个拥有数十名开发人员和至少4个部署环境的大型项目中：
配置Hibernate，使其在 * 本地 * 运行时自动 * 更新 * 模式（
ddl-auto: update）。这样，开发人员对实体的更改总是在他们本地工作时立即反映在他们的本地模式中，并且每个开发人员都可以在工作时适当地管理他的本地模式。然后使用diff工具或脚本（some examples here）捕获本地数据库示例与已知良好数据库示例（例如QA环境）之间的差异。该工具将差异捕获为SQL，开发人员可以按照适当的命名约定将其放入Flyway迁移文件中。
最后，我总是配置任何已部署的环境，以便Hibernate在启动时验证模式（
ddl-auto: validate）-这有助于避免在运行时出现差异或错误。这样做的好处是让Hibernate做它擅长的事情（生成SQL），同时保持对应用位置和时间的控制。这个过程还允许定制生成的diff/migration SQL，只要手动更改不与Hibernate验证的内容冲突，这是两全其美的。
这个过程确实需要开发人员和代码评审人员遵守一些程序规则（确保任何实体更改都有附带的迁移脚本），但这与我见过的任何其他过程/策略没有什么不同。