質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

88.93%

一対一の関係の場合は別テーブルにするか

受付中

回答 4

投稿

  • 評価
  • クリップ 0
  • VIEW 5,330

mhl

score 33

mysqlにデータを入れる際に、1対1の関係の場合はわざわざ、テーブルを作るのではなく、1テーブルにcolumnとしてデータを入れるのがいいのか、悩んでいます。

どなたか、ご教示をお願いします!!

例:
users

id name email tel
1 hoge hoge@example.com 03123456789

companies

id name user_id
1 hogecompany 1

ざっくりしたものですが、この場合はいちいち,
companiesというテーブルを作らずに、companyをいうcolumnをusersに入れるのがいいのでしょうか?
こいうusersにcolumnが少ない場合はそれのがいいと思いますがこれが、usersのcolumnが3,40になるような場合は、テーブルを分けて管理したのがいいのでしょうか?
テーブルを増やすのか、columnを増やすのかはどうやって判断すればいいのでしょうか?

DBのことを勉強中なので、質問自体が間違っていましたら、すみません!

よろしくお願いいたします。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 4

+5

email と tel にも言えることですが、いずれ一対一ではなく多対一にしたくなると思います。
私ならユーザー、メール、電話番号、会社の 4 つのテーブルを作ります。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/05/09 19:08

    ご回答ありがとうございます!
    会社に対して多対1にしたくなるのはわかりますが、メール、電話番号も多対1にしたくなるのはなぜでしょうか?

    キャンセル

  • 2017/05/09 19:13

    携帯と家と二つの電話番号があるからです。備考に入れてもいいのですが、電話番号は電話番号でまとめた方がフロントエンドが作りやすくなります。

    キャンセル

  • 2017/05/09 19:23

    ありがとうございます!

    大変参考になりました!

    キャンセル

+2

マスターテーブルとそうではないテーブルの概念を学んだ方が良いでしょう。
以下のサイトでは、マスタデータ・トランザクションデータと呼んでいますが同じことです。
http://www.graffe.jp/blog/392/

要は通常の運用では変更されない基本となるデータをマスタとします。
また同じ情報をひとつにまとめる場合も同様です(むしろこっちの方が比重が高い)
例えば社名が複数レコードに存在していると、運用面でも処理面でも問題です。
ですので、今回の場合では、

  • ユーザーマスタ
  • 会社マスタ

と考えるとよいです。
どちらも日常的に修正が入ることはないですよね?
ユーザー情報は、転居したときや結婚して姓が変わったときなど。
会社情報も、移転したとき、合併して社名が変わったときなど。

あとはどちらを中心に考えるかですね。

  1. このユーザーはどこの会社に属するのか
  2. この会社に属するのはどのユーザーか

1にした場合、ユーザーマスタに会社情報を紐づければ良いでしょう。
この場合のテーブル構成はこんな感じになります。

users

id name email tel c_id
1 hoge1-1 hoge1-1@example.com 03123456789 1
2 hoge1-2 hoge1-2@example.com 04123456789 1
3 hoge2-1 hoge2-1@example.com 05123456789 2
4 hoge2-2 hoge2-2@example.com 06123456789 2

companies

id name
1 hogecompany
2 hogecompany2

では2にした場合はどうでしょう。
会社情報にユーザー情報を持ちます。

users

id name email tel
1 hoge1-1 hoge1-1@example.com 03123456789
2 hoge1-2 hoge1-2@example.com 04123456789
3 hoge2-1 hoge2-1@example.com 05123456789
4 hoge2-2 hoge2-2@example.com 06123456789

companies

id name u_id
1 hogecompany 1
1 hogecompany 2
2 hogecompany2 3
2 hogecompany2 4

usersテーブルの方は変わりませんが、companiesテーブルはユーザー数分レコードができてしまって無駄が多いですね。
また会社名が複数レコードにあるので、会社名を変更したいという場合、複数レコード更新しないといけなくなり、マスターの意味がなくなってしまいます。

というわけで1のような構造にするのがRDMSでの一般的な設計方法になるかと思います。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/05/10 15:36

    ありがとうございます!

    大変勉強になりました!

    キャンセル

+1

  • usersのidをuid、nameをuname
  • companiesのidをcid、nameをcname

と切り分けて下さい
同じ会社に複数のユーザーが共存することを考えれば

userテーブルは
uid,uname,email,tel,cid
となります。

逆にcompaniesにuser_idが入ることはないような気がします

一つで管理してもいいですが、会社名が変更になった際に
正規化していればcompaniesを1箇所なおすだけで済みます

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/05/09 19:26

    ご回答ありがとうございます!
    columnの名前付け参考になります!

    一つ質問があります。
    companiesにuser_idではなくusersにcidを入れるのはなぜでしょか?
    逆だと、不備が起こるのですか?

    キャンセル

  • 2017/05/09 19:45

    一人のユーザーが複数の会社に所属するよりも
    1つの会社に複数のユーザーが所属している方が一般的です。

    Aさん、Bさん、CさんがX社、
    Dさん、EさんがY社にいるようなイメージです。

    このさユーザーテーブルのAさんのレコードにX社のcidが入るということでわかりますか?

    キャンセル

  • 2017/05/10 15:38

    わかりました!

    ありがとうございます!

    キャンセル

0

usersテーブルにcompaniesテーブルの情報を載せてはいけないわけではありません。ただし、以下の様な問題が起こる可能性があります。

・同一のcompany_nameのuserがいた場合、情報の重複する
・company_idやcompany_nameで検索したい場合に複数ヒットするので扱いが難しくなる(変更漏れの可能性)
・company_addressやcompany_phoneなどの項目が必要になると重複された情報が更に多くなる
・同一のcompany_nameの社名変更やその付随情報などの変更があった時に扱いが難しくなる(変更漏れの可能性)

逆にいうと、userとcompanyの一対一の関係が保証されるか、保証されなくても大した問題にならない場合は同じテーブルにしても構いません。例えばusersテーブルにzipとadressがあったとして、間違った郵便番号が登録されていたとしても通常は大した問題にならないとお考えます。郵便番号から検索することは無いからです。(もっとも間違った郵便番号が登録されたことが判明したら、そのレコードの修正は必要ですけどね。)

実際にどのような検索を行いどのように運用されるかによってテーブルの設計は変わってきます。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/05/09 21:48

    あと、そうそう通常は項目数が何十個にもなることはないです。”正規化”がきちんと出来ていればの話ですが・・・

    キャンセル

  • 2017/05/10 15:37

    ありがとうございます!

    大変参考になりました!

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 88.93%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る