数据库单个字段关联多张源表外键是否合理，有何更优处理方案

一、是否可以将EntityId设置为所有源表的外键？ #

不可以，原因如下：

• 标准外键约束的逻辑是：子表字段的值必须在关联的父表主键/唯一键字段中全部存在，如果给EntityId同时绑定10张源表的外键，就要求每条记录的EntityId必须同时存在于10张源表中，完全不符合业务逻辑（实际场景中EntityId仅属于其中某一张源表）。
• 数据库本身不支持这种“一条记录只匹配任意一个父表”的多态外键逻辑，强行添加约束会导致正常业务数据根本无法入库。

二、这类场景的更优处理方案 #

根据业务侧重可以选择以下三种常用方案：

方案1：添加实体类型标识（最常用，轻量高效） #

在Document表中新增EntityTypeCdId字段，关联实体类型枚举表EntityTypeCd，每条记录通过EntityTypeCdId标识当前EntityId归属的源表：

• 优势：无需大幅改动原有表结构，新增源表只需在枚举表加一条记录，查询逻辑简单，性能优异
• 一致性保障：常规场景通过业务层做校验即可，对一致性要求高的场景可以额外添加触发器/检查约束做数据校验

方案2：分字段设置独立外键（适合源表数量固定的场景） #

给每个源表单独创建可空的外键字段，比如OrderId、ContractId、CustomerId等，每个字段单独关联对应源表的主键，同时添加检查约束保证每次只有一个外键字段有值，其余为NULL：

• 优势：可以使用数据库原生外键约束保障数据一致性，逻辑直观
• 不足：源表数量如果后续有新增需要修改表结构加字段，字段过多会产生冗余

方案3：拆分独立关联中间表（规范性最高，适合源表持续新增的场景） #

取消Document表的EntityId字段，为每个源表创建独立的关联中间表，比如OrderDocument、ContractDocument，每张中间表只存对应源表ID和DocumentId，分别设置外键约束：

• 优势：完全符合数据库设计范式，无冗余字段，新增源表只需新增中间表无需改动现有表结构，数据一致性保障最好
• 不足：跨类型查询文档时需要关联多张中间表，SQL编写相对复杂

附：原始建表语句 #

CREATE TABLE [dbo].[Document](
    [DocumentId] [int] IDENTITY(1,1) NOT NULL,
    [EntityId] [int] NOT NULL,
    [DocumentGuid] [uniqueidentifier] NOT NULL,
    [DocumentTypeCdId] [int] NOT NULL,
    [DocumentName] [nvarchar](500) NOT NULL,
    [DocumentType] [nvarchar](500) NOT NULL,
    [DocumentData] [nvarchar](max) NOT NULL,
    [IsSuppressed] [bit] NULL,
    [CreatedBy] [nvarchar](200) NULL,
    [CreatedDt] [datetime] NULL,
    [UpdatedBy] [nvarchar](200) NULL,
    [UpdatedDt] [datetime] NULL,
 CONSTRAINT [PK_Document] PRIMARY KEY CLUSTERED 
(
    [DocumentId] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

ALTER TABLE [dbo].[Document]  WITH CHECK ADD  CONSTRAINT [FK_Document_DocumentTypeCd] FOREIGN KEY([DocumentTypeCdId])
REFERENCES [dbo].[DocumentTypeCd] ([DocumentTypeCdId])
GO

ALTER TABLE [dbo].[Document] CHECK CONSTRAINT [FK_Document_DocumentTypeCd]
GO

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