特別対談 #1 – クラスの継承関係をいかにDB設計に落とし込むか

たうこ:今日は神戸から友人のスーパーエンジニアである、かーもんが福岡に来てくれました👏
連絡して3時間で来るとか、さすがフッ軽太郎やね
今日はよろしくお願いします!

かーもん:おねがいします〜福岡明太子〜

たうこ:(福岡明太子・・・!?)よろしくお願いします!
かーもんって噂で聞いたけどエバンス本を枕元に置いて寝てるってマ?

かーもん:ちゃうで、枕がエバンス本なんやで

たうこ:だから今日異様に直角な寝癖なんか笑
それではさっそく本日の対談始めたいんやけど、最近かーもんのまわりでおもろい技術とかある?

かーもん:流行りもんではないけど、最近はオブジェクト指向のクラスを永続化する時にどうやってDBにマッピングするかについて調べてて、結構おもしろかったで

たうこ:おもろそうやな
それってORMのこと?

かーもん:ORM は基本的にテーブルと1対1のクラスを用意して、それとマッピングする手法だね
これも確かにありなんだけど、オブジェクト指向ではないなと思ってて
今回考えていたのは、オブジェクト指向に基づいて設計された純粋なクラスをどう永続化するか
その時に最適なテーブル構造はどの様なものかって感じやな

たうこ:ふーん、で、何かいい方法は見つかった感じ?

かーもん:一番のポイントはオブジェクト指向の継承構造をどうRDBMSで表現するかで
マーチン・ファウラーはPofEAAで3つのパターンを提案してる

具象テーブル継承
一番下層のサブクラス単位でテーブルを作る

単一テーブル継承
親クラス及び全てのサブクラスのプロパティを単一のテーブルにすべて書き込む

クラステーブル継承
親クラスおよびサブクラスごとにひとつひとつテーブルを作って、リレーションで親子関係を表現する

まあ、結局メリット・デメリットを考慮して最適な方法を選べって結論で、最強の方法があるわけではないんやけどな

たうこ:はいはい、関係データベース自体はクラスの継承関係を表現出来へんからテーブル設計とリレーションでその違いを吸収していくんやな
例えば抽象クラスを継承したサブクラスの実装が多い場合は具象テーブル継承でDB設計していくという認識でおk?

かーもん:その場合は具象テーブルかクラステーブル継承かな
共通部分(抽象クラス)に対する処理が多いかどうか、とかで判断するといいんじゃないかと

たうこ:なーるー
その辺も見ていかないといかんのやな
単一テーブル継承ってどんな時に使えそう?

かーもん:単一テーブル継承は、スピード感重視かつ、サブクラスが持つ項目数が少ない時とかかな

たうこ:そういうことね、スッと入ってきたわ
かーもんの関わってるプロジェクトではどんな感じでやってるか一例出せる?

かーもん:うちのプロジェクトだと、結局全部クラステーブル継承に落ち着いてしまったな〜
一覧で取得するときは、親クラスだけを取得して、詳細情報の取得ではサブクラスをID検索して取得するって感じ
あとは、 ORM がこういう複雑な継承関係のマッピングに対応している場合は、データベース構造としての保守しやすさで選んじゃってもいいって意見もあったな
その場合は単一テーブル継承も選択肢に入れやすいかも
具象テーブル継承は、どっちつかずで使い所が難しいね

たうこ:ほえぇ、めっちゃイメージ出来たわ
今日来てくれておおきにな(ノーギャラなのに)
また呼ぶから頼むわ(ノーギャラで)

2024年9月某日 スターバックス福岡パルコ店