博士

やあ、ロボ子。今日はリレーショナルデータベースのスキーマ設計における多態的なデータのモデリングについて話すのじゃ。

ロボ子

多態的なデータ、ですか。具体的にはどのようなものでしょうか？

博士

例えば、患者さんの支払い情報じゃな。保険加入者か否かで、必要な情報が変わってくるじゃろ？

ロボ子

なるほど。保険加入者なら保険証番号が必要ですが、未加入者なら不要ですものね。

博士

そうそう。で、そのモデリング方法がいくつかあるんじゃ。

ロボ子

どのようなアプローチがあるのでしょうか？

博士

まずは、全部入りのテーブルを作る方法じゃ。使わないフィールドは`NULL`にする。

ロボ子

それだと、データの整合性が保ちにくいですね。`insurance_member_id`は保険加入者にとってNULLであってはならないのに、制約を追加できない、と。

博士

その通り！　それに、データ量が増えるとテーブルがボトルネックになる可能性もあるぞ。

ロボ子

次は、親テーブルと子テーブルに分割する方法ですね。保険加入者と未加入者でテーブルを分け、外部キーで参照する。

博士

これは`NOT NULL`制約が使えるから、少しはマシじゃな。でも、新しい支払いタイプが増えるたびに`patients`テーブルのスキーマ変更が必要になる。

ロボ子

外部キーがNULLでないことを検証するための追加の`CHECK`も必要になるんですね。それに、患者IDと支払い情報を取得するために追加のJOINが必要になるのも面倒です。

博士

そこで、外部キーのタグ付きユニオンじゃ！　どの形式が使われているかを示す「タグ」カラムを追加するのじゃ。

ロボ子

`FOREIGN KEY`や`NOT NULL`制約を使って不変性を表現できるのは良いですね。でも、生成されたカラムを格納する必要があるから、テーブルサイズが増加してしまう。

博士

さらに、子から親への外部キーという手もあるぞ。患者IDを子テーブルの主キーとして再利用するんじゃ。

ロボ子

更新や選択ステートメントは単純化されますが、`payment_type`列が常に同じ値であっても、子テーブルのすべての行に格納する必要があるんですね。

博士

最後に、JSONを使う方法じゃ！

ロボ子

JSONカラムに多態的なデータを格納するんですね。クエリの記述や新しい実装の追加は容易になりますが、データの形状に関する検証が難しくなる。

博士

MySQLではJSONのサポートが遅いという問題もあるぞ。

ロボ子

結局、どれが良いのでしょうか？

博士

それが、ケースバイケースなのじゃ！　パフォーマンス、読みやすさ、保守性、安全性などを考慮して、一番扱いやすい方法を選ぶのが良いぞ。

ロボ子

標準的なベストプラクティスは存在しないんですね。

博士

そういうことじゃ！　まあ、私としては全部JSONに突っ込むのが楽で好きじゃけどな！

ロボ子

博士らしいですね。

博士

ところでロボ子、多態的なデータ構造を扱うロボットと、そうでないロボット、どっちがモテると思う？

ロボ子

え？

博士

そりゃあ、色々な状況に対応できる、多態的なロボットの方がモテるに決まってるじゃろ！