中間テーブルで勘違いしていた内容にレビューの指摘で気づいたので投稿しました。なんでも中間テーブルにすればいいと思ってた、先週までの俺は恥ずかしいやつです。
記事を読むのにかかる時間
- 2分
結論
- 中間テーブルを作る前にテーブル毎の関係性を考える。多対多の場合は有効。１対多の場合だと、中間テーブルを作らなくても管理できる。
- 現状１対多の場合でも、将来的に仕様が変わる可能性がある場合は、最初から中間テーブルにしておいた方が楽。
- 中間テーブルを作ることで、手間が増えるので、作ればいいというものではない
背景
次の仕様のテーブル設計をしてました。
- ある機能のアクセスキーを管理するテーブルを新たに作る
- access_keyはユーザー毎に発行され、複数ユーザーが同じaccess_keyを持つことはない
指摘前のテーブル設計
usersテーブル
{
id
user_name
}
user_access_keyテーブル
(中間テーブルを作った)
{
user_id
access_key_id
}
access_keysテーブル
{
id
access_key
expired_date
}
しかし、リーダーからの指摘で
- 1対多のテーブルなので中間テーブルしなくていいよ
ときて、
ほにょ!????? となり、
中間テーブルについて、とにかく使えばいいと思っていので
改めて調べました。
テーブル同士の関係性について
1対多のイメージ
- 一つテーブルが別のテーブルの複数レコードと関連づいている状態
- 今回の仕様。access_keyが各ユーザーに紐づいている状態
多対多のイメージ
- あるテーブルの複数レコードが別のテーブルの複数レコードと関連づいている状態
- 今回の仕様に
複数ユーザーが同じaccess_keyを使っている場合を追加した状態
中間テーブルを作る場合の条件
- 多対多の関係性を持つ場合
- 二つのテーブルの主キーを外部キーとする
自分が間違えたこと
- 一対多の関係性だったのに、安易に中間テーブルを作ってしまった。一対多だった場合は下記のようにすれば十分だった(将来的に仕様が変わることもない)
usersテーブル
{
id
user_name
}
access_keysテーブル
{
access_key_id
user_id
access_key
expired_date
}
- 中間テーブルにした場合のデメリットを考慮できていないかった。
- Join作業が増え、大変になる.
- テーブルが増えるので、データ容量が増える
最後に
中間テーブルを作ればいいというものではなさそうなので気をつけていきましょう