SQL中自定义数据类型BIDENT是什么？为何不用外键实现表间关联？

dbo.bident的定义与工作原理 #

首先需要明确：bident不是SQL标准或SQL Server的内置数据类型，它是当前数据库内自定义的别名数据类型（User-Defined Data Type），你的理解有部分偏差：它本身不负责跨表关联逻辑，核心作用是统一关联字段的类型规范。

• 定义逻辑：这类自定义ID类型一般是通过类似如下的语句创建的：

  CREATE TYPE dbo.bident FROM BIGINT NOT NULL
  

  大部分业务场景下会把它封装为固定长度的BIGINT类型，专门用于存储所有表的业务主键、外关联ID字段。
• 工作原理：别名类型本质是对系统基础数据类型的封装，所有使用dbo.bident的字段，底层存储规则、操作逻辑和它所基于的基础类型（通常是BIGINT）完全一致。统一使用该类型定义所有ID相关字段，可以从根源上避免关联字段类型不匹配的问题，比如出现主表ID是BIGINT、关联表字段定义为INT导致的隐式转换、索引失效等问题。

该场景不使用外键实现关联的常见原因 #

用同自定义类型的字段做逻辑关联、不创建物理外键是业务开发中的常见选择，核心原因有以下几点：

• 性能损耗：外键会在每次写入、更新、删除数据时触发跨表关联校验，高并发写入场景下会带来明显的性能开销，数据量较大的表这一开销会被进一步放大。
• 业务灵活性受限：很多业务会实现软删除、数据归档、临时数据写入等逻辑，外键的强校验规则会限制这类操作的执行，比如要归档主表的历史数据时，必须先删除子表的关联数据，不符合归档需求。
• 分布式架构不兼容：如果业务使用分库分表、微服务架构，关联表可能分布在不同的库甚至不同的数据库实例中，外键无法跨实例生效，只能靠业务层保证数据关联的一致性。
• 迭代效率低：业务快速迭代阶段，表结构、关联关系调整的频率较高，外键约束会大幅提升结构调整的成本，很容易出现修改表结构时被关联外键卡住的问题。

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