数据库设计中使用标记联合替代频繁UNION是否属于反模式？

结论 #

你这套设计是完全可行的，属于关系型数据库实现多态实体存储的常见方案之一，非常适配你需要频繁查询全量命名对象的业务场景。

方案优势 #

• 大幅降低公共查询开发成本：所有公共属性（ID、创建人、名称等）都统一存储在NamedObjectWrapper表，查询全量命名对象列表、按公共属性过滤/排序等需求直接查单表即可，完全不需要写多表UNION逻辑，开发效率提升非常明显。后续新增命名对象类型时，仅需新增对应类型枚举值和可空外键字段即可，不需要修改现有公共查询逻辑。
• 公共属性一致性更易保障：公共字段不需要在多表冗余存储，不会出现多表公共字段更新不同步的数据一致性问题。

需要规避的潜在问题 #

你需要在数据库层面加上强制校验规则，避免业务代码异常写入不符合规则的数据：

1. 加CHECK约束保证三个外键字段有且仅有一个非空，参考约束逻辑：(NamedObject1 IS NOT NULL) + (NamedObject2 IS NOT NULL) + (NamedObject3 IS NOT NULL) = 1
2. 加CHECK约束保证NamedObjectType和非空外键的对应关系，例如当NamedObjectType = 1时仅允许NamedObject1字段非空，避免出现类型标记和关联实体不匹配的问题
3. 合理设计索引：给NamedObjectType加索引适配按类型筛选的需求，三个外键字段分别加索引，提升关联查询对应子表的性能。

方案适用边界 #

如果后续你的命名对象类型扩展到5种以上，NamedObjectWrapper表的外键字段会越来越多，可读性和可维护性会下降，到时候可以考虑换成逻辑外键的通用设计（仅存ObjectType和ObjectID两个字段，放弃物理外键约束），但你当前只有3种类型的场景下，完全不需要做这个调整。
相比你提到的「三类对象分表+冗余公共属性」的方案，你现在的设计在你的业务场景下收益明显更高，不需要为了追求严格的范式牺牲开发效率和数据一致性。

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