继承关系在内存和DB中的映射

使用

将若干相似的类映射为单表,对拥有许多特殊数据的类使用具体表继承.
对高层次使用类表继承,对低层次使用具体表继承.

Single Table Inheritance
- 在DB中将类继承层次设计为一个单表,表中各列代表不同类中的所有域.
- 运行机制
  - 每个类负责把与之相关的数据保存在表的一行中.表中其它不相关的列留空.
  - 通过表中的Type字段来决定向内存中加载对象时,应该实例化那个类来创建该对象.
    - 可以直接使用类名称
    - 或者需要经过翻译的Code域.
  - 保存数据的代码可以由层超类负责.
- 使用时机
  - 优点
    - 只需要关注一个DB表.
    - 获取数据时不必进行连接.
    - 对继承层次的重构(在父子之间挪动某个域)不需要修改DB.
  - 缺点
    - DB表的列和对象的域不是一一对应的.
    - 空间的浪费.
    - 可能太大的单表.过多的索引被频繁上锁.导致访问效率低下.
    - 域名称可能重复(加上类名做区分可以解决).
Class Table Inheritance
- 每个DB来代表一个类.
- 运行机制
  - 类中的域直接映射到相应表中的字段上.
  - 表的行链接问题
    - 使用公用的主键.由于超类表针对其它子类表中的每一行都有对应的一行.所以主键必须在各表间唯一.
    - 每个表都有自己的主键,并使用超类表的外键把各行联系在一起.
  - 最大的问题是如何有效地把数据从多个表中取回.
    - 对每个表都进行一次调用会造成多次调用.
    - 一次链接来处理多个表,会在表数目较大时,产生性能问题.
  - 通常,对于指定的查询,并不清楚具体需要链接那些表.如查询一组运动员.
    - 使用外链接来在某些表没有数据时有效地进行链接.
    - 先读根表,然后找出下一个该读取的表.但是这样会有多次查询.
- 使用时机
  - 优点
    - DB表更容易理解,且没有空间浪费.
    - 领域模型和DB之间的关系简单明了.
  - 缺陷
    - 加载一个对象需要访问多个表(也就是需要链接)
    - 字段在继承层次中上下移动会导致DB重构.
    - 对超类的频繁访问会导致瓶颈.
Concrete Table Inheritance
- 内存中的每一个具体类对应一个DB表.

运行机制
- Db表中的列包含着具体类和其所有祖先类中的所有域.超类中的所有域在子类的DB表中都会被复制.
- 需要保证键在继承层次中所有的表键都是唯一的.
  - 需要一个键分配系统来记录表间键的使用情况.
  - 要么避免使用超类的域,要么使用包含表ID的复合键.
- 引用完整性问题
  - 例如,慈善活动和Player的关联.由于没有Player对应的Db表.所以无法使用外键来构建链接表.
  - 此时,可以忽略引用完整性.
  - 或者,使用多链接表.DB中的每个表都有一个链接表与之对应.
使用时机

优点

每个DB表都是自包含的,并且不含有不相关的域.
具体映射器读取数据时不需要链接操作.
只有在类被访问时,对应的DB表才会被访问.分散了访问负载.

缺陷
- 主键很难处理.
- 不能把数据库关系加到抽象类中.
- 域在继承树上移动时,须更改表定义.
- 超类的域改变时,会有很多的子类DB表连带更改.
- 超类上的一次查找需要检查所有表.

Inheritance Mapper
- 运行机制
  - 查找方法定义在具体子类上,因为它要返回一个具体类.OO不允许改变已声明方法的返回值类型.
    - 基本行为:在DB中找到合适的行,实例化正确类型的对象(子类决定),并用来自DB的数据来加载对象.
    - 子类映射器在加载子类特有的数据后,一直向上调用它的超类方法.
  - 插入和更新
    - 都使用保存方法.可以在超类上定义接口.
    - 插入:创建一个新行,将对象中的数据用Save钩子方法保存起来.
    - 更新:值保存数据,也使用Save钩子方法.
    - 与加载类似,每个类保存其特有的数据,之后调用超类的保存方法.
  - 一个支持保存和加载的抽象类
    - Abstract Player映射器负责向DB中加载和保存特定的Player数据.
      - 它是一个抽象类.其行为只有具体的映射器子类使用.
    - 独立的Player映射器.
      - 提供了操作的接口.
      - 提供了查找方法.
      - 覆盖了插入和更新方法.
      - 其只负责找到应该处理某个具体任务的具体映射器,并把任务委托给该具体映射器.

巴特西

继承关系在内存和DB中的映射

最新文章

热门文章