继承树场景下，标识映射数量的决策

标识映射的数量可以从”整个会话一个映射”到”每个类各一个映射”之间灵活选择——只有当数据库整体有唯一键时才适合只用单一映射，好处是访问入口只有一个地方，也不会踩到继承相关的坑。如果用多个映射，最自然的做法是每个类或每张表对应一个映射，前提是数据库方案和对象模型基本一致；如果二者不一致，通常让映射按对象划分会比按表划分更省事，因为对象本来就不需要了解底层映射的复杂关系。继承结构是这里最容易踩坑的地方：假设”小汽车”是”车辆”的子类型，是该用一个映射覆盖整棵继承树，还是给每个子类各自分开建映射？分开建映射会让多态查找（比如”给我一个车辆，不管它具体是哪个子类”）变得更麻烦，因为每次查找都必须挨个去查所有相关映射；因此作者更倾向于给每棵继承树整体用一个映射，代价是必须保证这个键在整棵继承树范围内都是唯一的——如果这棵继承树用的是具体表继承（每个具体类各自一张表，天然没有共享的超类表），要保证这份跨表的键唯一性会相当困难。可迁移启发：涉及继承层次的查找/索引类结构（不只是标识映射，也包括缓存键、路由表等），”按需要多态查询的最大范围”来统一设计索引粒度，往往比”按最细的物理单元各自拆分”更省心——只是这个选择会反过来对底层的键分配方案提出更严格的约束。