数据库设计最佳实践：index与index_trade_data_daily表关联方案选型

方案1合规性判定 #

方案1的复合主键设计本身符合关系数据库第三范式规范，但存在两处不符合规范的细节：

1. 逻辑关联的index_id未设置外键约束，不符合参照完整性要求，会存在数据不一致风险：比如index表中某条指数记录被删除后，index_trade_data_daily中对应的历史交易数据会成为无归属的孤行，也可能出现写入不存在的index_id的无效数据。
2. 你提到的“近似一对一关联”的判断有误，实际是典型的一对多关联：单条指数记录可以对应多条不同交易日期的日收益数据。

两种方案的优劣对比 #

方案1（index_id+date作为复合主键，无单字段主键） #

• 优势
  • 无冗余字段，所有字段均具备实际业务含义
  • 主键天然具备唯一约束，无需额外新增唯一索引，index_id+date维度的查询直接走主键索引，查询效率更高
  • 存储成本更低，无需额外存储无意义的主键字段与对应的索引
• 劣势
  • 若后续业务需要新增其他表关联index_trade_data_daily，需要携带两个字段作为关联外键，关联逻辑更繁琐，SQL编写成本更高
  • 部分ORM框架对复合主键的适配性差，需要额外编写适配代码，提升了开发成本
  • 当前未设置外键的实现版本存在数据一致性隐患，可通过补充外键约束解决，不属于方案本身的缺陷

方案2（新增无业务含义的单字段id作为主键，补充index_id+date唯一约束） #

• 优势
  • 单字段主键的关联逻辑更简洁，后续其他表关联日交易数据时仅需存储一个id字段即可
  • 几乎所有ORM框架都对单字段自增主键提供原生支持，开发成本更低
  • 唯一约束已经保证了同一指数同一交易日期不会出现重复的收益数据，业务一致性有保障
• 劣势
  • 存在一个无业务含义的冗余字段，但是该字段带来的存储成本极低，基本可以忽略
  • 需要额外维护index_id+date的唯一约束索引，写入时的性能开销略高于方案1，对绝大多数金融业务场景来说该开销完全可以接受

选型建议 #

• 如果你的业务没有其他表需要关联index_trade_data_daily，且当前使用的技术栈对复合主键支持良好，选择方案1更简洁，注意补充index_id指向index.id的外键约束即可。
• 如果业务后续存在扩展可能，或者使用的ORM框架对复合主键支持不好，选择方案2更省心，无业务含义的主键带来的开发便利性收益远大于其微不足道的存储、性能成本。

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