はじめに

「テーブル・DBを設計するときのさいきょうの極意」を完全に理解したので
初心者（私）向けに共有する記事です。

どうぞ揉んでいただければ幸いです。対戦よろしくお願いします。

さいきょうの極意

初心者が「テーブル・DB設計して」と言われると、
「アソシエーションってあったよね・・・バリデーションも？中間テーブルを使うときと使わないときと・・・」と大変に混乱し、何から手をつけていいかわからなくなります。

そんなあなたにこれ！

・テーブル・DB設計は「属性」と「関係」の２つだけ

・「属性」は必要なものを書くだけ

・「関係」は 1:1 / 1:N / N:N しかない（しかも、ほとんど 1:N）

これが極意だ！！！

一般的な、「ユーザーがいて、投稿ができて、コメントといいねができるサービス」で考えてみましょう。
users / posts / comments / likes のテーブルが必要そうです。

属性：`users`

求められているものを書くだけです。
今回は「id」「ユーザーネーム」「年齢」「email」「パスワード」が必要だとしましょう。

はい、完成です。
intとstringは「型」です。例えば「名前」は「数値」ではなく「文字列」です。よってstring
まあ、型は慣れです。すぐ慣れます。

親切心でこのように書いてあげてもいいでしょう。未来の自分が喜びます。
PKは「プライマリキー」のことで、「一意の識別子」のことです。
難しい言葉ですが、「オリジナルでユニークなid」と覚えればよいです。

属性：他のテーブル

長くなるので割愛しますが、以下のようにしました。

FKは「フォーリンキー（外部キー）」のことで、別のテーブルのプライマリキーを参照する、ということです。
postsのuser_idなら「投稿を作成したuserをusersのidを参照し識別する」ということですね。

関係：`users` vs `posts`

一人のユーザーを想像しましょう。
そのユーザーは複数の投稿をすることができますか？
→はい。

次に、一つの投稿を想像しましょう。
その投稿は複数のユーザーによって書かれましたか？
→いいえ。

ということで、1:Nの関係です。簡単！

このとき、「0であることもある」かどうかで表記が変わります。

投稿が0のユーザー・・・ありえます。
作成者が0の投稿・・・ありえません。

ということで、先程の図の関係（ users : posts = 1 : (0 or N) ）になります。
※-|--（１）は-||--と書くこともあります。今回は後者の書き方。

※2024/06/25 追記 -|--（１）と-||--（必ず１）が違う意味をもつ場合もあるようです。

関係：`users` vs `comments`

一人のユーザーが複数のコメントをする・・・ありえます。
一つのコメントが複数のユーザーによってつくられる・・・ありえません。

コメントが0のユーザー・・・ありえます。
作成者が0のコメント・・・ありえません。

よって、1 : (0 or N)です。

関係：`posts` vs `comments`

一つの投稿に複数のコメントがつく・・・ありえます。
一つのコメントが複数の投稿に紐づく・・・ありえません。

コメントが0の投稿・・・ありえます。
投稿に紐づかないコメント・・・ありえません。

よって、1 : (0 or N)です。

関係：`likes` vs `users` / `posts`

commentsと同じです。

vs `users`

一人のユーザーが複数のいいねをする・・・ありえます。
一つのいいねが複数のユーザーによってされる・・・ありえません。

いいねが0のユーザー・・・ありえます。
ユーザーが0のいいね・・・ありえません。

よって、1 : (0 or N)です。

vs `posts`

一つの投稿に複数のいいねがつく・・・ありえます。
一つのいいねが複数の投稿に紐づく・・・ありえません。

いいねが0の投稿・・・ありえます。
投稿に紐づかないいいね・・・ありえません。

よって、1 : (0 or N)です。

完成！

完成です！！簡単！！

お気づきでしょうか。今回は全て1:Nでした。
とにかく、1:Nが基本です。

1:1 / N:Nの例

次に、1:1 / N:Nの例も見てみましょう。

特に、N:Nは1:Nの次によく出てきます。

1:1

「社員」と「社員証」

社員（社員番号・名前・部署）と、社員証（カード番号・有効期限）は1:1です。
「社員が複数の社員証を持つこと」「社員証が複数の社員に属すること」どちらもあってはなりません。

N:N

「著者」と「書籍」

一人の著者が複数の書籍を書くこと・・・ありえます。
一つの本が複数の著者に書かれること・・・ありえます。

N:Nですね。このときは中間テーブルを使用します。

中間テーブルを使用する理由については

を読んでいただくのが良いと思います。

そして、中間テーブルを使用すると・・・そうです。1:Nになります。

やはり1:Nが基本なんだ・・・！

おわりに

以上、実務経験のない初心者の考えた「さいきょうの極意」でしたが、いかがでしたでしょうか。

つっこみどころあると思います。ぜひコメントいただければ幸いです。

さて、次は何を書こうかしら・・・

はじめに

さいきょうの極意

・テーブル・DB設計は「属性」と「関係」の２つだけ

・「属性」は必要なものを書くだけ

・「関係」は 1:1 / 1:N / N:N しかない（しかも、ほとんど 1:N）

これが極意だ！！！

属性：users

属性：他のテーブル

関係：users vs posts

関係：users vs comments

関係：posts vs comments

関係：likes vs users / posts

vs users

vs posts

完成！

1:1 / N:Nの例

1:1

「社員」と「社員証」

N:N

「著者」と「書籍」

おわりに

属性：`users`

関係：`users` vs `posts`

関係：`users` vs `comments`

関係：`posts` vs `comments`

関係：`likes` vs `users` / `posts`

vs `users`

vs `posts`