Liquidbase与实体定义中重复设置唯一约束是否有积极意义？

在项目中同时在Liquibase脚本和JPA实体类里定义复合唯一约束，确实存在几个实际的积极作用：

• 应用层提前校验，减少数据库交互
  JPA Provider（比如Hibernate）会在代码执行到持久化操作时，先根据实体类的@UniqueConstraint注解校验数据唯一性，不用等到SQL发送到数据库才触发约束检查。这样能更早捕获非法数据，避免无效的数据库请求，而且抛出的异常更贴近业务代码上下文，方便开发快速定位问题。

• 提升代码可读性，实现自文档化
  实体类里的约束注解相当于直接把业务规则写在了代码里，其他开发者不用去翻阅一堆Liquibase变更脚本，只要查看实体类就能清楚知道该实体的数据唯一性要求，尤其适合不熟悉数据库脚本的后端开发人员。

• 兼容JPA生态工具
  很多JPA相关的工具依赖实体类注解来识别约束：比如开发阶段用hibernate.hbm2ddl.auto生成测试库表结构时，没有实体类的约束注解，生成的表会缺少唯一约束；还有一些ORM可视化工具、代码生成工具，也需要通过注解来识别这些规则，保证开发环境的结构和生产环境一致。

• 作为变更的双重校验机制
  后续如果需要修改唯一约束（比如调整列、修改约束名称），实体类的注解会提醒开发者同步更新Liquibase脚本，减少只修改其中一边导致的开发/测试/生产环境结构不一致的问题。

注意事项 #

必须保证两边的约束定义完全一致：约束名称、列的顺序、列名都要一一对应，否则可能出现数据库已存在约束，JPA尝试创建同名但不同规则的约束导致报错。另外，生产环境建议禁用hibernate.hbm2ddl.auto的自动更新功能，避免JPA自动修改数据库结构和Liquibase的脚本管理冲突。

内容的提问来源于stack exchange，提问作者mihu