多态关联存在未使用列时，是否应拆分为独立回复表？

这其实是个非常典型的业务设计权衡问题，我来帮你拆解下两种方案的优劣势，你可以结合自己的实际场景做决定：

一、继续使用多态关联的利弊 #

优点 #

• 代码维护更省心：只需要一个Reply模型，关联逻辑统一，不用重复写两套回复相关的代码，后续如果新增其他需要回复的模型（比如评论、动态），直接复用这套关联就行，扩展成本极低。
• 聚合查询更方便：比如要统计全站总回复数、某个用户的所有回复记录，直接查replies表就搞定，不用跨多个表做UNION操作。
• 数据库表数量少：不用额外创建多张回复表，数据库结构更简洁。

缺点 #

• 存在冗余字段：确实像你说的，ProfilePost的回复完全用不上position字段，会有字段空置的情况。不过说实话，单个字段的存储成本在现代数据库里微乎其微，除非你的回复量达到千万级甚至更高，否则这个冗余几乎可以忽略。
• 数据一致性需要代码保障：数据库层面没法限制ProfilePost的回复不能设置position，需要在业务代码里做校验（比如在Reply模型中根据repliable_type判断是否允许赋值position），避免出现无效数据。

二、拆分回复表的利弊 #

优点 #

• 表结构完全贴合业务：thread_replies保留position，profile_post_replies只存必要字段，没有任何冗余，数据结构更严谨。
• 数据库约束更严格：可以给thread_replies的position字段设置非空约束，从底层避免无效数据，不用依赖代码校验。
• 单表性能更优：每张回复表的数据量更小，索引的效率更高，针对特定类型回复的查询速度会更快。

缺点 #

• 代码复杂度上升：需要维护两个独立的回复模型（ThreadReply和ProfilePostReply），关联逻辑、业务逻辑都要写两遍，后续新增回复类型还要重复这套流程，维护成本更高。
• 聚合查询麻烦：要查用户所有回复、全站总回复数这类跨类型的统计，必须用UNION合并多个表的结果，SQL和代码都会更繁琐。
• 数据库表数量增多：多了两张回复表，后续的备份、迁移等运维操作也会多一点工作量。

三、给你的具体建议 #

1. 如果你的业务回复类型少（目前只有Thread和ProfilePost，短期内不会新增），且数据量不大，优先选保留多态关联。冗余字段的问题可以通过代码层面的逻辑校验解决，比如在Reply模型里做判断：当repliable_type是ProfilePost时，强制position为NULL或者不允许赋值。
2. 如果你的业务对数据严谨性要求极高，或者两种回复的后续业务逻辑差异会很大（比如要给Thread回复加排序、给ProfilePost回复加点赞统计等不同字段），或者回复量已经达到百万级以上，那拆分表会是更稳妥的选择。

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