テーブル・DB設計するときの極意 - Qiita

はじめに 「テーブル・DBを設計するときのさいきょうの極意」を完全に理解したので 初心者（私）向けに共有する記事です。 どうぞ揉んでいただければ幸いです。対戦よろしくお願いします。 さいきょうの極意 初心者が「テーブル・DB設計して」と言われると、 「アソシエーションってあったよね・・・バリデーションも？中間テーブルを使うときと使わないときと・・・」と大変に混乱し、何から手をつけていいかわからなくなります。 そんなあなたにこれ！ テーブル・DB設計は「属性」と「関係」の２つだけ 「属性」は必要なものを書くだけ 「関係」は 1:1 / 1:N / N:N しかない（しかも、ほとんど 1:N） これが極意だ！！！ 一般的な、「ユーザーがいて、投稿ができて、コメントといいねができるサービス」で考えてみましょうか。 users / posts / comments / likes のテーブルが必要

[TriQ]

まじどんなテーブル作ったら良いか分からん！って人に及第点を取らせることができる良い記事なんじゃないかな。これくらいできてれば十分な現場も多いでしょ

[pmint]

users.id を users.user_id にするとSQLが単純になる。user と users も全部統一して、users.users_id か user.user_id にするほうが単純。あと、ゆとりが大事。DBに厳密さは要らない。

[maid_h]

T字形ERデータベース設計技法も古典だけど面白いよ

[tmdtky]

極意…？

[Futaro99]

データベース完全に理解した

[uunfo]

社員証は実際は再発行とか更新とかあるから1:1にはならんのよ

[atico]

いいね！bodyはstring型ではなくtext型にしないとデータが入りきらないと思う。次はindexや複合indexを使ったunique保証かな？

[moronbee]

ていねい

[jiro68]

こんな題名の記事を書ける人はものすごく凄い人だなと思う。私はかれこれ30年近くRDBと戯れているが未だ「極意」を理解したと思えないので。ちなみに記事の中身は読んでない。

[yarumato]

“初心者（私）向けに共有。テーブル・DB設計は「属性」と「関係」の２つだけ！　「属性」は必要なものを書くだけ。　「関係」は 1:1 / 1:N / N:N しかない（しかも、ほとんど 1:N）　これが極意だ！”

[miruto]

メモメモ

[asiamoth]

DB設計苦手だけどスッと頭に入った。良い記事！⏎途中に出てくるER図のスクショをGeminiに投げて「SQL書いて」で一発で出てきた。スゲェ時代だ……。

[ch1248]

ええやん