先生と生徒の会話形式で理解しよう

生徒

「Railsのモデルで、似たようなデータ構造をどう整理すればいいか分かりません……」

先生

「Railsには、STIやポリモーフィック関連という仕組みがあります。うまく使うと、とても整理しやすくなりますよ。」

生徒

「名前が難しそうで、初心者には無理そうに感じます……」

先生

「大丈夫です。日常生活の例えを使いながら、ゆっくり説明していきます。」

1. STIとは？1つの表で種類を分ける考え方

STIは「Single Table Inheritance」の略で、日本語にすると「1つのテーブルを使った継承」という意味になります。 Railsのモデル設計でよく登場する仕組みです。

継承とは、「共通の性質をまとめる」考え方です。例えば、動物園で考えると、犬も猫も「動物」という共通点があります。名前や年齢は共通ですが、鳴き声などは違います。

STIでは、データベースのテーブルを1つだけ用意し、その中に「種類」を表すカラムを持たせます。 Railsでは、このカラム名がtypeになります。


class Animal < ApplicationRecord
end

class Dog < Animal
end

class Cat < Animal
end

この場合、dogsテーブルやcatsテーブルは作りません。 animalsテーブル1つで、犬も猫も管理します。初心者の方は、「同じノートに色ペンで種類を書き分ける」というイメージを持つと分かりやすいです。

2. STIのメリットと落とし穴

STIの大きなメリットは、設計がシンプルなことです。テーブルが1つなので、管理や保存が分かりやすくなります。共通の処理もまとめやすく、Railsらしい書き方ができます。

しかし、注意点もあります。種類ごとに項目が大きく違う場合、使わないカラムが増えてしまいます。これは、空欄だらけのアンケート用紙を全員に配るような状態です。

また、後から種類が増え続けると、テーブルがどんどん複雑になり、初心者には理解しづらくなります。

ポリモーフィック関連は、「どのモデルとも関連できる」という柔軟な仕組みです。名前は難しそうですが、考え方はとてもシンプルです。

例えば、「コメント」を考えてみましょう。コメントは、記事にも写真にも付けられます。それぞれ専用のコメントテーブルを作るのは大変です。

そこで、ポリモーフィック関連を使うと、コメントは「どの種類の投稿にも付けられる」という設計ができます。


class Comment < ApplicationRecord
  belongs_to :commentable, polymorphic: true
end

この仕組みは、「どんな箱にも貼れる付箋」のようなものです。 1つの仕組みで、いろいろな対象に対応できます。

ポリモーフィック関連は便利ですが、何でもかんでも使うと、後で困ることがあります。データベース上では、関連先が文字情報として保存されます。

そのため、データの整合性をデータベース側で強く守れません。これは、「手書きメモで管理している」状態に少し似ています。

また、検索や集計が複雑になりやすく、初心者が後からコードを読むと、分かりにくく感じることがあります。

STIは、「中身がほぼ同じで、種類だけ違う」場合に向いています。動物やユーザー種別などが代表例です。

一方、ポリモーフィック関連は、「1つの機能を、いろいろなモデルに付けたい」場合に便利です。コメント、いいね、画像などがよく使われます。

どちらも万能ではありません。初心者のうちは、「本当に必要かどうか」を考えながら使うことが大切です。

STIやポリモーフィック関連を使わず、普通にテーブルを分ける設計も立派な選択です。分かりやすさは、初心者にとって最大の武器です。

最初から難しい仕組みを使うより、シンプルな設計で理解を深める方が、長くRailsを学び続けられます。

Railsのモデル設計では、「将来の自分が読めるか」をいつも意識することが大切です。