多态关联在数据库中如何设计？commentable_type 和 commentable_id 有什么问题？

简化版

多态关联用 target_type + target_id 表示一条记录可以关联不同类型对象，比如评论可以挂文章、视频或商品。它灵活，但数据库无法直接建立普通外键，数据完整性、查询优化和级联删除都更难，需要谨慎使用。

详细版

多态关联常见于评论、附件、点赞、操作日志等通用模块。表结构可能是 comment(id, target_type, target_id, content)。

优点是表少、模型统一，新增一种被评论对象时不用新建评论表。缺点是数据库不知道 target_id 到底指向哪张表，无法用一个外键约束多个目标表；查询也常需要按类型分支。

替代方案包括：按目标建独立关联表、抽象出统一资源表、使用事件/日志模型、或在应用层严格校验。选型要看完整性要求、查询模式和目标类型数量。

完整版教学

一、多态关联解决什么问题

假设系统里文章、视频、商品都可以被评论。直接设计三张表 article_comment、video_comment、goods_comment 会重复很多字段。

多态关联把目标对象抽象成类型和 ID：

CREATE TABLE comment (
  id BIGINT PRIMARY KEY,
  target_type VARCHAR(32) NOT NULL,
  target_id BIGINT NOT NULL,
  content TEXT NOT NULL,
  KEY idx_target (target_type, target_id)
);

这样一张评论表就能挂到多种对象上，扩展新对象也方便。

二、最大问题是外键失效

普通外键只能指向一张确定的表。target_id 有时指向文章表，有时指向视频表，数据库无法声明一个“根据 target_type 动态切换”的外键。

这意味着引用完整性要靠应用代码保证。如果文章被删除，评论是否删除、保留或隐藏，都要额外处理。

数字例子：每天删除 1000 个视频，如果应用漏掉评论清理，1 年就可能留下 36.5 万条悬挂评论。

三、索引和查询也要围绕类型设计

多态表一定要有 (target_type, target_id) 组合索引。因为常见查询是“查某个文章的评论”或“查某个视频的点赞”。

如果只给 target_id 建索引，不同类型对象的 ID 可能重复，查询还要过滤 type，效率和语义都不好。

查询	推荐索引	说明
查目标评论	`(target_type, target_id)`	最核心
查用户评论	`(user_id, created_at)`	用户中心
查最近评论	`(created_at)`	后台审核

四、什么时候不适合多态关联

如果关联对象需要强外键、强事务、复杂 join 和一致删除，多态关联就不合适。比如支付流水关联订单、退款单、结算单，最好不要用一个 target_type + target_id 糊住。

如果不同目标对象的评论规则差异很大，例如商品评论有评分、晒图、SKU，文章评论没有这些字段，统一表也会变得臃肿。

多态关联适合“弱关联、通用行为、可容忍应用层校验”的模块。

五、有哪些替代方案

第一种是独立关联表：文章评论、视频评论分开，完整性更强，但表更多。第二种是统一资源表：所有可评论对象先注册到 resource 表，评论只关联 resource_id。

统一资源表可以恢复外键能力：

resource(id, type, biz_id)
comment(resource_id) -> resource(id)

代价是多一层映射，查询链路更长，但适合平台化资源模型。

六、常见误区与追问

误区：多态关联只是少建几张表。 它牺牲了数据库级外键和一部分查询清晰度。
误区：应用层保证就一定可靠。 跨服务、脚本、后台修复都可能绕过应用校验。
误区：所有通用模块都适合多态。 强一致、强审计、复杂差异字段的场景不适合。
追问：索引怎么建？ 至少建 (target_type, target_id)，再按用户、时间等查询补索引。
追问：如何处理目标删除？ 明确级联删除、软删除隐藏或保留历史，并做异步清理和审计。

七、加强记忆

记忆钩子：多态关联像万能插座，什么都能插，但地线和保险丝要自己补；越核心的电器，越不能随便接。

回答这题要承认它的灵活性，同时讲清外键、索引、删除和替代方案。面试官最怕听到“加两个字段就行”，那通常意味着没意识到完整性代价。

简化版

详细版