DBテーブルの多対多の概念を知る

DBにおける多対多のリレーションシップ

ユーザー（usersテーブルのレコード）が部活動（clubsテーブルのレコード）に参加している、というようなモデルを考える時、一人のユーザーが一つの部活動に参加している場合には users.clubs_id のように関連先のIDを持つカラムを作ることで一対多の形で実現できます。

ここで、ユーザーがサッカー部とテニス部を兼部しているというようなケースを考えると、これまでの設計ではうまく対応できません。users.club_id2のようなカラムを作って対応していくのは、ユーザーの兼部の数が3つ、4つ...と増えるたびにDBにカラムが追加されていって、変更に弱いものになってしまいます。

そこで、membersのような中間テーブルを作成して、usersとclubsの仲介をさせる事で柔軟なテーブル構造を作成します。この状態はusersの1レコードから見た時clubsのレコードが多数関連し、逆にclubsの1レコードから見た時もusersのレコードが多数関連づくので、多対多の構造と言います。

テーブル分割を避けたくなるなら、JOINに慣れていないかも

DBの分割を避けてしまう心理として「分割するとSELECTの際に面倒が増えてしまう」という捉え方があります。大抵の場合この理由で適切な分割を避けるのはあまり良い結果になりません。リレーショナルデータベース（後述）は、テーブル分割を適切に行うことでデータのキッチリした格納を目指す考え方のデータベースであると思います。

JOINによって結合することでテーブル分割したものを検索時に自由に再構築できるので、この事を学習して自分のものにすればテーブルの分割も怖くなくなるでしょう。ワンセットでJOINについても学習する事をお勧めします。

また、テーブルの分割の考え方ついて詳しくは「DBの正規化」について学ぶとこのあたりがよくわかるかもしれません（慣れるとあまり正規化という言葉に拘らなくともある程度は自然に分割できると思います）。

言葉

• 中間テーブル: 今回のmembersテーブルのように、二つのテーブルのIDを持って、両者の仲立ちをするテーブルのことです
• リレーショナルデータベース: RDBとも呼ばれます。MySQLやPostgreSQLを思い浮かべてくれれば大丈夫です

DBを修正するのは影響が大きく、比較的コストが高い

プログラミングのコードを修正するのと、DBのカラムやテーブルを修正するのとでは、一般的にはDBの修正の方がコストが高いです。プログラミングのコードが間違っていた時に直して公開し直すのはgitなどを利用していれば容易に行えますが、DBは一度変更を加えると保存されている（永続化されている）情報がある為に、簡単に元に戻したり付け替えたりすることが難しいのです。

その為、DBの変更操作を減らせる方がコストを減らせるという事になります。ただし、その為に制約を緩めるなどして情報の堅牢性を犠牲にしてしまうと困ることが多い、という事を制約を扱う別のエントリなどで言及しています。