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
- 必要物がすべてそろった