Concrete Table Inheritance

Represents an inheritance hierarchy of classes with one table per concrete class in the hierarchy.

具象クラス1つにつき1テーブル
パターンの命名に悩んだよ、という話
- Leaf Table Inheritanceのほうがわかりやすいが、やめた
- 具象クラスはクラスツリーのリーフだけとは限らない
  - 中間ノードも具象クラスたりうる

How It Works

具象クラスにつき1テーブル
- 祖先の具象クラスのフィールドももつ
  - キーも
祖先に具象クラス = 対応するテーブルのあるクラスがある場合、カラム定義は重複する
キーの取り扱いに注意
- テーブルをまたいで一意でなければならない
  - 【補】 footballers, cricketers, bowlers の3テーブル全体でキーは一意でなければならない
  - 【補】「他のテーブルに値が『ない』」ことを保証するSQLの制約はない
    - cf. 「他のテーブルに値がある」ことの保証がFK制約
  - Identity Fieldパターン(未習)でテーブルをまたいで一意なキーを管理
- 他のシステムで使われているDBに接続する場合、とくに厄介
  - テーブルをまたいだキーの一意性を保証できない
  - 【補】近くて遠いかもしれないが、RDBと外部IF両方からデータを取ってくるようなケースもこれか
    - 今携わっている案件がまさにこれ
  - どうする
    - キーが重複しちゃったら親クラスのフィールドを使わない
    - テーブル識別子との複合キーにして、重複しないようにする
    - インタフェースにaccessorメソッドを定義し、派生クラスで実装してフィールドをマージする
      - スカラならどちらかを返す
      - コレクションならマージする
参照整合性問題
- 抽象クラスのテーブルを持たないためにおきる
- クラス図
- 【補】ERDはこうなる
  - しかしSQLでは複数のテーブルを参照するFKを定義することはできない
    - 【補】SQL Antipatterns "Polymorphic Associations"
      - フレームワーク等でサポートされていれば良いのかもね
パフォーマンス問題
- 抽象クラスのコレクションが欲しいような場合、どのテーブルにクエリすればよいかわからない
  - Class Table Inheritanceと同じ問題
- 複数回クエリ
- OUTER JOIN
leaf table inheritanceとして引用されることも
- クラス階層の葉ノードクラス1つにつき1テーブル
- 中間ノードに具象クラスがいなければ同じ結果になる
  - いてもあまり変わらない
    - 【補】部分木にSingle Table Inheritanceになる感じ

When to Use It

Single Table Inheritance, Class Table Inheritanceと比べたメリデメ
- メリ
  - 各テーブルで情報が完結している
  - 関係ないカラムがない
  - JOINない
  - 各クラスのテーブルにアクセス負荷を分散できる
- デメ
  - PKの扱いの難しさ
  - 抽象クラスのテーブルを作らないため、抽象クラスへの関連を制約として課すことができない
  - Domain Modelクラスのフィールドのリファクタリングがテーブル定義に跳ねる
    - Class Table Inheritanceほど深刻ではない
    - Single Table Inheritanceよりは影響大
    - 親クラスのフィールドの変更は、同クラスと子孫クラスのテーブル定義に跳ねる
  - 抽象クラスのfind時は全テーブルアクセス
    - 複数回クエリ
    - OUTER JOIN
Table Inheritanceパターン3兄弟は混用できる

Example: Concrete Players(C#)

英語

punningly
- 語呂を合わせて
hook up
- 接続する
self-contained
- 必要物がすべてそろった

勉強日記

チラ裏

PoEAA ch12 Concrete Table Inheritance

Concrete Table Inheritance

How It Works

When to Use It

Example: Concrete Players(C#)

英語