WebサービスなどでDB設計をするとき、よく適当にテーブルを設計して「このテーブルにもID一覧持たせておけばよくないかな」と考えてしまいがちな人向けに、RDBでなぜ「中間テーブル」を用いるのかを「多対多」をキーワードになるべくまとめます。

情報モデル

以下のようなモデルを例にします：

問題起点

「Postについているタグ名を持たせたいならpost テーブルに tag_name からなる列を持たせれば良いじゃん？」と思うことがあります。しかしこれはRDBの設計思想に反します。

例：

SELECT t.id, t.name
FROM PostTag pt
JOIN Tag t ON pt.tag_id = t.id
WHERE pt.post_id = 1;

これにより、Postに繋がる複数のタグをもれなく取得できます。

1つのPostに複数のTag、そのTagは別のPostにも使われる。
これが「多対多 (N:N)」の構造。

RDBでは、多対多を表現するときに「中間テーブル」を作ります：

Post (1) ---< PostTag >--- (1) Tag

NG例：

post_id	tag_names
1	"アウトドア,一人OK,自然"

Tagは名前や色情報を含んだ「定義情報」として別て管理するのがメンテナンス性が高い。

タグ名が欲しければ、JOINするだけ。

今回のメモは、自分でDBを設計する際に「なぜ中間テーブルを作るのか」を説明できるようにするための理解の基礎を整理したものです。
もっと難しいテーマ(グループ化や縦方スケーリング)を考える前に、この基本を理解していることが重要です。

全体のテーブル設計の流れやユーケースの定義、ER図化なども別記事で何回かに分けて書く予定です。