12.8 类表继承

为什么 12.8 类表继承值得单独学习

设想一个订单系统把员工分成 Employee、Engineer 和 Manager。对象侧希望复用 Employee.id、name 等公共状态，又希望工程师有 skill、经理有 budget。如果把所有字段塞进一张宽表，会得到很多与类型无关的空列；如果每个子类完全复制公共字段，又会把一次公共字段改名扩散到多张表。

本章解决的不是“ORM 怎样声明继承”，而是一个更小、更硬的问题：怎样让数据库中的多行仍然表示同一个对象身份。类表继承把公共状态放在父类表，把专属状态放在子类表；子类行通过同一个 ID 找回父类行。它用 JOIN 换取字段边界清晰，用事务和约束换取身份不被拆散。

本页依据 Martin Fowler 的作者图书页、模式目录和出版社目录独立重写，不复现原书正文、插图或代码。目录只限定学习范围；员工继承层次、SQL、TypeScript 映射、评审矩阵和交互图均为本课程原创教学材料。

先建立直觉：一份身份如何分布在三张表里

先猜一猜：如果 Engineer 对象的 id 是 42，employees 表里有 (42, "Lin")，那么 engineers 表应该使用什么值来指向它？答案不是再生成一个 9001，而是继续使用 42。这个值就是共享主键：它同时回答“这是哪个对象”和“它属于哪一行父类数据”。

数据库中的三个层次可以这样读：employees 保存所有员工都有的字段，engineers 和 managers 只保存差异字段；当应用要恢复一个工程师时，映射器先按同一个 ID 连接两张表，再构造一个对象。这里的映射器不是数据库的替代品：它负责翻译，数据库仍负责主键、外键和事务约束。

如果父类还有一层抽象中间类，连接链会继续变长。例如 StaffMember → Employee → Engineer 对应三张表，最深的查询需要沿着共享 ID 逐层 JOIN。先观察图中的 ID 是否保持不变，再回答：你愿意为每次读取支付几次 JOIN，取决于这个继承层次是否真的有稳定的公共身份，而不是取决于 ORM 的默认配置。

核心模型：父类表保存共性，子类表保存差异

共享身份比字段复制更重要

类表继承的最小模式是一组同名身份列：

CREATE TABLE employees (
  id   BIGINT PRIMARY KEY,
  name VARCHAR(120) NOT NULL
);
 
CREATE TABLE engineers (
  id    BIGINT PRIMARY KEY REFERENCES employees(id),
  skill VARCHAR(120) NOT NULL
);
 
CREATE TABLE managers (
  id     BIGINT PRIMARY KEY REFERENCES employees(id),
  budget DECIMAL(12, 2) NOT NULL
);

子类表的 id 同时是主键和指向 employees.id 的外键。参照完整性因此拒绝两种错误：孤立的工程师行，以及没有对应子类行却被应用误构造成工程师的对象。公共字段不会在子类表重复，专属字段也不会污染不属于该类型的行。

写入与删除必须有明确顺序

创建工程师时，先插入父类行，再插入子类行；删除工程师时，先删除子类行，再删除父类行。两步必须位于同一个事务中，否则中途失败会留下只有父类、只有子类，或已经失去完整对象的半成品。数据库的外键会挡住非法顺序，但它不能替你决定事务何时开始、错误怎样返回。

type Engineer = { id: number; name: string; skill: string };
 
async function insertEngineer(db: Db, engineer: Engineer) {
  await db.transaction(async (tx) => {
    await tx.employees.insert({ id: engineer.id, name: engineer.name });
    await tx.engineers.insert({ id: engineer.id, skill: engineer.skill });
  });
}
 
async function loadEngineer(db: Db, id: number): Promise<Engineer | null> {
  const row = await db.queryOne(
    `SELECT e.id, e.name, g.skill
       FROM employees e
       JOIN engineers g ON g.id = e.id
      WHERE e.id = ?`,
    [id],
  );
  return row ? { id: row.id, name: row.name, skill: row.skill } : null;
}

这里的 Db 和 SQL 占位符只是说明持久化契约的伪接口，不绑定某个 ORM。可验收的行为是：父类插入失败时没有子类行；子类插入失败时整个事务回滚；加载只在两行都存在时返回完整的 Engineer。若需要允许“暂时没有具体类型”的员工，就必须显式定义状态，而不能靠一条缺失的子类行猜测类型。

查询类型越宽，JOIN 代价越明显

读取单一子类时，employees JOIN engineers 很直观。读取所有员工的多态查询则需要决定数据库如何表达类型：可以对每个子类做 LEFT JOIN，再由 CASE 判断非空列；也可以分别查询每个子类并 UNION ALL 成统一结果。两者都必须记录缺失子类行的处理方式，不能把空结果默认为某个类型。

多态查询不是类表继承的错误，而是它的账单：公共字段只存一份，代价是更长的读取计划和更复杂的结果组装。若系统几乎只按具体类型读取，这个账单通常可接受；若每个请求都要扫描十几种子类，选择前应把 JOIN 数量、索引命中和映射器代码量写进评审记录。

目录单元到教学证据

12.8 类表继承

本章只覆盖一个官方目录单元：12.8 类表继承。单元键为 poeaa24-pattern-19-class-table-inheritance，模式族为 mapping。本章的证据链不是“表能建起来”，而是能从同一个 ID 追踪父子行，证明插入和删除的事务顺序，并在多态查询变宽时指出拒绝信号。

评审一份实现时，固定使用员工样本：Employee(42, "Lin")、Engineer(42, "compiler")、Manager(77, 1200000)。记录四个观察项：共享身份是否唯一，父子行是否一起提交，查询是否能恢复具体类型，新增公共字段是否只需要改父类表。任何一项没有可复现的 SQL、代码或截图证据，都不能只用“ORM 已处理”带过。

专属代码案例：员工继承的映射边界

把一次员工保存切成“对象 → 父类行 → 子类行 → JOIN 恢复”四个观察点。领域代码拥有 Engineer.skill 的业务校验，映射器把对象翻译成两张表的行，数据库用外键保护共享身份；三者各自的失败都要能被定位。

一个实用的评审卡包含五项：模式键为 poeaa24-pattern-19-class-table-inheritance；当前裁决是“公共字段稳定、具体类型常被单独读取、共享主键可在事务内维护”；观测项包括 JOIN 深度、多态查询比例、公共字段迁移次数、父子写入失败率和索引命中；拒绝条件是“每个请求都必须扫描大量子类，或跨服务写入使父子行无法保持同一事务边界”。

下面的图把这张卡拆成三步。动手试前先预测：第 2 步把 skill 从 employees 移到 engineers 后，哪一个 ID 必须保持不变；第 3 步加入“列出所有员工”后，查询复杂度会在哪个位置增加。切换步骤时观察变化，再用练习题写出你的选择理由。

三步交互实验：从建表到多态查询

选择与拒绝矩阵

和单表继承相比，类表继承减少了无关类型的空列，但读取需要 JOIN；和具体表继承相比，它避免复制公共字段，但多态读取不再是简单的单表查询。选择的依据应是实际读写比例和演化证据，不是“规范上更面向对象”。

常见误区

本章小结

类表继承的关键不是“每个类都有一张表”，而是父类行与子类行用同一个主键表示同一对象。共享主键和参照完整性守住身份，事务顺序守住写入与删除，映射器通过 JOIN 把多行恢复成一个对象；多态查询则把额外读取成本明确暴露出来。

因此，公共字段需要唯一来源、具体类型读取占主导且父子写入能保持同一事务时，类表继承是有证据支撑的选择。若多态扫描成为热路径，或父子行跨越无法协调的边界，应把测量结果带回单表继承、具体表继承或读写分离方案，而不是继续把 JOIN 藏在框架默认值后面。

本章练习

SELECT e.id, e.name, g.skill
FROM employees e
JOIN engineers g ON g.id = e.id
WHERE e.id = 42;

名词解释

前后导航

• 上一页：12.7 单表继承
• 下一页：12.9 具体表继承

参考资料

• Martin Fowler 作者图书页：核对全书主题、章节定位与作者公开说明。
• Martin Fowler 模式目录：核对 Class Table Inheritance 的模式名称与公开摘要。
• Pearson 出版社目录页：交叉核对英文版出版信息与目录范围。