使用业务键（Business Key）作为外键关联和查询依据的实践指南

在 Spring Data JPA 中，不建议将 IBAN、编码等业务字段用作主键或外键；应优先采用技术主键（如 @Id + 自增/UUID），业务键仅用于查询优化与语义标识。

在数据库建模和 JPA 实体设计时，不少开发者容易踏入一个“逻辑陷阱”：既然像 IBAN、产品编码、邮箱这类业务字段本身就具备唯一且非空的特性，那直接拿来当主键，甚至用来建立表关联，岂不是既直观又省事？

想法很自然，但实践起来，往往是给未来的自己“埋雷”。这种看似简洁的方案，背后隐藏的长期维护成本，可能远超你的想象。

✅ 推荐方案：技术主键 + 业务键辅助查询

一个稳健的设计原则是：主键，请务必交给那些稳定、可控、且毫无业务含义的技术键。 比如下面这个银&行账户的例子：

@Entity
public class BankAccount {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id; // 技术主键，完全由系统控制

    @Column(unique = true, nullable = false, length = 34)
    private String iban; // 业务键，具备唯一约束，但不参与关联
    // 其他字段...
}

那么，在其他需要关联这张表的实体里，该引用什么呢？答案是明确的：引用 BankAccount.id，而不是 iban。

@Entity
public class Transaction {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "account_id") // 关联到 BankAccount.id
    private BankAccount account;
    // ...
}

✅ 查询业务键：无需 @NaturalId，Spring Data JPA 原生支持

接下来是另一个关键问题：如果我想通过 IBAN 或产品编码来查询记录，该怎么办？其实很简单，直接在 Repository 接口里声明对应的方法就行，完全没必要引入 Hibernate 特有的 @NaturalId 注解。

public interface BankAccountRepository extends JpaRepository {
    Optional findByIban(String iban); // ✅ 推荐：简洁、标准、高效
    List findByIbanStartingWith(String prefix);
}

Spring Data JPA 足够智能，它能识别到实体中 iban 字段上的 @Column(unique = true) 约束。当然，为了确保查询性能，你得在数据库层面为这个字段建立索引，可以通过 @Index 注解显式声明：

@Table(indexes = @Index(columnList = "iban", unique = true))
public class BankAccount { ... }

⚠️ 这里需要特别提醒一下：@NaturalId 是 Hibernate 提供的一套特有机制，主要服务于二级缓存等特定场景（比如 session.bySimpleNaturalId().load()）。在标准的 Spring Boot + Spring Data JPA 技术栈里，绝大多数情况下都用不上它。引入它反而会增加框架耦合度，降低代码的可移植性。除非你非常明确地需要跨 Session 的自然 ID 缓存语义，否则，最好避开它。

❌ 为什么不推荐业务键作主键/外键？

道理说了这么多，我们不妨再深入看看，把业务键当作主键或外键，具体会带来哪些麻烦：

• 稳定性风险：业务规则是会变的。今天 IBAN 是34位，明天国际标准升级了怎么办？邮箱的域名政策调整了怎么办？产品编码体系整个重构了又怎么办？一旦这些字段成了主键，任何格式或逻辑的变更都是伤筋动骨。
• 迁移成本极高：想象一下，如果 iban 已经是主键，那么所有引用了它的外键表（比如交易记录表、余额历史表）都得跟着改。修改列类型、重建索引、迁移数据……这一系列操作无法原子化完成，风险和数据一致性挑战巨大。
• 性能与兼容性问题：字符串类型的主键（尤其是长文本），在数据库的 B+ 树索引中，会比整数或 UUID 占用更多空间，比较速度也更慢。此外，一些分布式数据库或分库分表中间件，对非数字主键的支持可能并不友好。
• ORM 映射复杂化：如果业务键是复合字段，你很可能得用上 @IdClass 或 @EmbeddedId，这会让实体关系映射变得晦涩难懂，同时还得小心翼翼地实现 equals 和 hashCode 方法，负担不轻。

✅ 最佳实践总结

说到底，关键在于职责分离：让主键专心负责标识“存在”，让业务键安心负责“识别”。二者各司其职，才是构建健壮、可持续数据架构的坚实基石。