RailsモデルとActive Record基礎｜STIとポリモーフィック関連の選び方・落とし穴・代替設計

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

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のメリットと落とし穴

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

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

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

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

3. ポリモーフィック関連とは？相手を選ばない関連

3. ポリモーフィック関連とは？相手を選ばない関連

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

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

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

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

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

4. ポリモーフィック関連の注意点

4. ポリモーフィック関連の注意点

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

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

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

5. STIとポリモーフィック関連の選び方

5. STIとポリモーフィック関連の選び方

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

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

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

6. 代替設計という考え方

6. 代替設計という考え方

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

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

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