在多态关联表中用null id存储默认值是否属于不良实践？

在具备多态关联的表中，使用null的entity_id条目存储默认值是否属于不良实践？

例如存在一张meta_tags表：

其中entity_id列值为null的条目包含所有App\Models\Product的默认元标签，第二条条目对应id=10的Product的元标签，将替代默认值使用。示例的原始SQL查询如下：

select `products`.`id`, `products`.`name`, 
  coalesce(`mt`.`title`, `mt_default`.`title`) `mt_title`,
  coalesce(`mt`.`description`, `mt_default`.`description`) `mt_description`,
  coalesce(`mt`.`keywords`, `mt_default`.`keywords`) `mt_keywords`
from `products`
left join `meta_tags` `mt` on (`mt`.`entity_id` = `products`.`id` and `mt`.`entity_type` = 'App\Models\Product')
left join `meta_tags` `mt_default` on (`mt_default`.`entity_id` IS NULL and `mt_default`.entity_type = 'App\Models\Product')

想了解该方案是否为不良解决方案？

这个方案不算不良实践，但有其适用场景和潜在局限，具体来看：

优点 #

• 实现简单：无需额外维护单独的默认值表，直接复用现有多态关联表结构，降低数据库复杂度。
• 查询逻辑直观：通过coalesce和两次左联就能快速获取实体自身值或默认值，代码可读性较强。
• 扩展性尚可：后续新增其他实体类型的默认值时，只需添加对应entity_type且entity_id为null的条目即可。

潜在问题 #

• 数据约束风险：若没有额外校验逻辑，同一entity_type下可能出现多条entity_id为null的默认值条目，导致查询返回重复数据，破坏默认值唯一性。建议给(entity_type, entity_id)添加唯一约束（注意部分数据库允许多个null，可能需要触发器或业务逻辑辅助限制）。
• 索引效率：当meta_tags表数据量较大时，两次左联的查询性能可能受影响。建议给(entity_type, entity_id)建立复合索引，并覆盖查询用到的title、description、keywords字段，提升检索速度。
• 语义模糊：entity_id为null在业务逻辑上代表“所有该类型实体的默认值”，但从表结构本身看，null通常表示“未关联任何实体”，可能给后续维护的开发者造成理解混淆，需在表注释或业务文档中明确该规则。

总结 #

如果业务场景中默认值类型不多、数据量不大，且能做好数据约束和文档说明，这个方案完全可行。但如果后续默认值逻辑复杂（比如分层级、多维度默认），或数据量增长较快，可考虑将默认值拆分到单独表中，让结构更清晰、性能更可控。

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