核心摘要: Core Data 和 SwiftData 在处理实体继承时，默认采用 单表继承 (Single Table Inheritance) 策略。这意味着父实体及其所有子实体的数据都存储在同一张 SQLite 表中。这种设计虽然简化了查询逻辑，但在处理大量异构子实体时，可能会因字段冗余（Sparse Columns）导致存储效率和读写性能的下降。
问题背景
与许多关系型数据库 ORM 方案不同，Core Data 和 SwiftData 作为对象图管理框架，将“实体继承”视为核心特性之一。这使得开发者可以像编写原生 Swift 类一样，构建具有继承关系的数据模型。
然而，许多开发者并不清楚这一功能在 SQLite 层面的物理存储机制。在不适用的场景（如子实体差异巨大且数据量极高）中使用继承，往往是导致应用启动变慢和查询卡顿的隐形杀手。
底层机制：单表继承 (Single Table Inheritance)
在 Core Data 或 SwiftData 生成的 SQLite 文件中，通常遵循“一个 Entity 对应一张表”的规则。但一旦引入继承关系，这个规则就会发生改变。
核心机制： Core Data/SwiftData 不会为每个子实体创建单独的表。相反，它会将父实体及其所有子实体的数据合并存储在同一张表中（通常以父实体的名称命名）。
例如，假设你有一个 Publication 父实体，以及 Book、AcademicPaper 三个子实体：
在 SQLite 层面，系统会创建一张包含了所有可能字段的“超级表”。为了容纳各个子实体特有的属性，这张表采用了冗余模式：
- 包含父类
Publication的所有公共字段。 - 包含
Book的特有字段（如isbn）。 - 包含
AcademicPaper的特有字段（如journal）。
当你在该表中存储一个 Book 对象时，属于 AcademicPaper 的字段将全部被置为 NULL。
这种设计的主要目的是为了多态查询（Polymorphism）：无论你是查询父实体（“查找所有出版物”），还是查询特定子实体，Core Data 只需要扫描这一张表即可，无需进行昂贵的 SQL JOIN 操作。
冗余存储与性能权衡
虽然 SQLite 对 NULL 值存储进行了深度优化（稀疏列存储优化），但在以下场景中，性能问题依然不容忽视：
- 宽表问题：如果子实体种类繁多且属性各异，会导致这张表拥有大量的列（Wide Table）。在 Swift 6 / iOS 26 环境下，虽然硬件性能提升，但加载包含大量
NULL值的宽行依然会消耗额外的内存带宽。 - 索引效率：所有子实体共用一张表，意味着索引也会变得庞大，可能会影响插入和更新的速度。
- 数据迁移：修改任何一个子实体的模型（例如增加字段），都需要触碰这张包含所有数据的核心大表。
结论与建议
不要因为潜在的性能损耗就完全摒弃继承功能。对于大多数移动端应用（数万条数据级别），现代设备的计算能力完全可以消化这种冗余带来的开销。
何时使用继承：
- 子实体之间共享大量公共属性。
- 需要频繁进行多态查询（例如：在同一个 List 中混合显示
Book和NewsPaper）。
何时避免继承：
- 子实体之间属性差异极大，几乎没有公共字段。
- 某个子实体的数据量是其他子实体的数量级倍数。
- 不需要进行统一的父类查询。。
如果你想亲眼看看 Z_ENT 是如何标记这些数据，以及这些 NULL 值在 SQLite 中到底长什么样，请参考我的底层分析：揭秘 Core Data 在 SQLite 中的隐藏字段与表结构。
如果你正在纠结是否使用继承，建议阅读 Core Data 中的模型继承：适用场景与陷阱 获得更详细的指导。