会计账户建模方案抉择：单表架构还是双表架构？

方案对比与结论 #

Option A：分表+映射表 #

• 核心优势：
  • 表结构天然区分账户类型，业务语义清晰，后续维护时能直接明确两类账户的边界。
  • 映射表的规则约束极易通过数据库原生机制实现：
    • 映射表仅需包含external_account_id（外键指向ExternalAccount表）和internal_account_id（外键指向InternalAccount表）两个字段。
    • 给external_account_id添加唯一约束，直接保证一个外部账户只能关联一个内部账户；内部账户无唯一约束，天然支持一对多关联。
    • 由于两个外键分别指向不同表，从根源上杜绝了“两个外部账户互相关联”的可能，无需额外校验逻辑。
• 潜在不足：两类账户的公共字段会重复存储，后续修改公共字段时需同步更新两张表。可通过数据库表继承（如PostgreSQL的INHERITS、SQL Server的表类型）优化：将公共字段抽离到父表Account，ExternalAccount和InternalAccount作为子表仅存储专属字段（如ExternalAccount的clientId），兼顾类型区分与字段复用。

Option B：单表+映射表 #

• 核心问题：
  • 映射表的规则约束难以通过数据库原生机制可靠落地：要限制“仅外部账户关联内部账户”，需校验映射的两个账户中一个clientId非空、另一个为空。但部分数据库（如MySQL 5.7及更早版本）会忽略CHECK约束，必须依赖触发器或应用层逻辑校验，增加了维护复杂度和数据不一致风险。
  • 单表结构语义模糊，每次查询特定类型账户都需添加WHERE clientId IS NOT NULL或WHERE clientId IS NULL条件，长期来看会降低代码可读性与查询效率。

最终建议 #

优先选择Option A（分表+映射表，可选表继承优化字段重复问题）。数据库原生约束是保障数据一致性最可靠的方式，能避免后续业务迭代中因应用层逻辑疏漏导致的规则破坏。

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