【MySQL】１対１でテーブルをあえて分ける

mysqlを使用してデータベースを作成しているのですが
データベースでテーブルを分けるときって

【アカウントテーブル】
ID
アカウント 名
アカウント　パスワード
名前
住所
電話番号
職業

【職業テーブル】
職業ID
職業名

というような１対多というのはよく組むとおもうんですが
下記のような

【アカウント情報テーブル（アカウント情報）】
アカウントID
アカウント 名
アカウント　パスワード

【アカウント情報テーブル（プロフィール情報）】
アカウントID
名前
住所
電話番号
職業

１対１の関係でテーブルをジャンル（エンティティ）ごとに複数にわけて
あとでリレーションして一個にまとめるというのはデータベース的にあまりよろしくないのでしょうか？

何故、こんなことしたいかというと、１テーブルあたりのカラム数がかなり多くなってくると
PHPでデータベースを書き込んだり呼び出したりする時に毎度多くのカラムを取り扱わなければならず
SELECTで、カラムを一個一個選んで行かないといけません。
しかし、取り扱いたいカラムは大抵の場合あるジャンルだけなので
リレーションするかしないかで、あるジャンルのデータだけを取り扱えれば
効率がよくなるのでは？　というのがあります。
また、視覚的にカラムの把握もしやすくなります。

この１対１テーブルは、DB設計的にどうなでしょうか？

No.3 ベストアンサー 回答者： ToOrisugaru 回答日時： 2012/05/16 21:48

一般的に（ＭＹＳＱＬに限らず）ＤＢ設計的には、分けるのが正しいです。

メリットは、変更に強いということです。
たとえば、画面イメージが変わった、帳票のイメージ（項目が減った、増え
た）など、設計段階および製造段階においてユーザー要望または、設計
バグ等により変更されることが多々あります。
そのような場合、利用単位にテーブルを作成していては、その都度テー
ブルの変更もあるかと思います。
テーブルを変更していては、それまでにその変更したテーブルを利用し
ているアプリケーションも変更する可能性がでてきます。そのことにより
変更のたびにシステムを全て見なおさなければならなくなり膨大にコス
トを消費してします罠に陥る可能性があります。
なので、設計レベルにおいて、業務に特化してエンティティを設計し、そ
れに沿ってテーブルを分けることが本筋かといえます。
また、設計者以外の人がそのテーブル構成を見て、大筋のシステムを
理解できるなどがあります。
設計から製造まで一人の人が行うってことはあまりないですからね！
説明せずに理解してくれることは非常に助かります。
このへんか、メリットではないでしょうか！

但し、あまりＤＢ設計に忠実に行うことによってデメリットもあります。
テーブル数及び項目数が多くなり、テーブルアクセスのレスポンスが低
下することがあります。
なぜならば、ＤＢは項目単位に管理されており、実際利用するときには
、複数の項目を連結して利用するため、多くの項目を一度い表示すると
きなどはそれがネックになりレスポンス低下を招く可能性があります。

この場合、そのへんも考慮してＤＢ設計らしからぬ設計を行う場合があ
ります。たとえば、複数の項目をひとまとめにして、一つの可変項目に
納めてしまい、テーブルアクセス時の項目連結を抑えてることにより性
能を上げるとか。上記例ぐらいなら問題ないと思いますが１テーブルに
数千近くの項目数があるような設計になれば検討する事項といえるか
と思います。（お使いの環境にもよると思いますが）

　

この回答へのお礼

回答ありがとうございます。
１テーブル３００カラムくらいになっており
その300カラムは外部からインポートして取得したレコードが入るようになっています。
それにプラス、独自の追加カラムを足そうと考えています。
とりあえず、足す文は分離させることにしてみます。

お礼日時：2012/07/14 09:35

No.2 回答者： yambejp 回答日時： 2012/05/16 12:49

＞効率がよくなるのでは？

わけることによるメリットはほぼなく、命題の内容をみるかぎり
効率がさがることはあってもあがることはないように見受けられます。

ただ、心情的にわけて管理したいというのであれば、
この程度のオーバーヘッドは個人レベルで管理するDBにおいては
分けてもさほど問題になることはないと思います

わける意義があるものとすればざっと思い付きでこんなのが挙がるかと
・１項目に２つ以上のデータを収集する必要があるもの
・逆に任意で入力するようなNULLが多発するようなもの
・履歴データを保持する必要があるもの
・頻繁に追加・更新がかかるような項目
・検索につかわれないような無駄に大きなバイナリデータ
・項目によってそれを統括管理する人がことなる場合

また極度にアクセスが集中するような想定で
カリカリにチューニングするのであれば
逆に分けた方がよいかもしれませんが、たいていその手のサイトは
もっと別の部分でボトルネックがくるので、そこまでシビアに
テーブルを管理することはないかもしれません。

この回答へのお礼

回答ありがとうございます。

お礼日時：2012/07/14 09:27

No.1 回答者： t_ohta 回答日時： 2012/05/16 12:36

認証用の基本情報とプロフィール情報を分けたりと、用途が違う（SELECTするタイミングが違う）場合はテーブルを分けておく方が、負荷などを考えた場合有効な方法だと思います。

必ずセットで使う情報の場合は分けることによって負荷をかけてしまう場合があるので、その場合は１つのテーブルにまとめるべきだと思います。

この回答へのお礼

回答ありがとうございます。

お礼日時：2012/07/14 09:27