• ベストアンサー
※ ChatGPTを利用し、要約された質問です(原文:【MySQL】1対1でテーブルをあえて分ける)

1対1でテーブルをあえて分ける

このQ&Aのポイント
  • mysqlを使用してデータベースを作成しているのですが、データベースでテーブルを分けるときって1対1の関係でテーブルをジャンルごとに複数にわけてあとでリレーションして一個にまとめるというのはデータベース的にあまりよろしくないのでしょうか?
  • 1テーブルあたりのカラム数が多くなるとPHPでデータベースを書き込んだり呼び出したりする時に毎度多くのカラムを取り扱わなければならず、効率が悪くなる可能性があります。
  • 1対1テーブルでは、特定のジャンルのデータだけを取り扱えるため、効率的にデータを抽出することができます。また、リレーションすることで視覚的にもカラムの把握がしやすくなります。

質問者が選んだベストアンサー

  • ベストアンサー
回答No.3

一般的に(MYSQLに限らず)DB設計的には、分けるのが正しいです。 メリットは、変更に強いということです。 たとえば、画面イメージが変わった、帳票のイメージ(項目が減った、増え た)など、設計段階および製造段階においてユーザー要望または、設計 バグ等により変更されることが多々あります。 そのような場合、利用単位にテーブルを作成していては、その都度テー ブルの変更もあるかと思います。 テーブルを変更していては、それまでにその変更したテーブルを利用し ているアプリケーションも変更する可能性がでてきます。そのことにより 変更のたびにシステムを全て見なおさなければならなくなり膨大にコス トを消費してします罠に陥る可能性があります。 なので、設計レベルにおいて、業務に特化してエンティティを設計し、そ れに沿ってテーブルを分けることが本筋かといえます。 また、設計者以外の人がそのテーブル構成を見て、大筋のシステムを 理解できるなどがあります。 設計から製造まで一人の人が行うってことはあまりないですからね! 説明せずに理解してくれることは非常に助かります。 このへんか、メリットではないでしょうか! 但し、あまりDB設計に忠実に行うことによってデメリットもあります。 テーブル数及び項目数が多くなり、テーブルアクセスのレスポンスが低 下することがあります。 なぜならば、DBは項目単位に管理されており、実際利用するときには 、複数の項目を連結して利用するため、多くの項目を一度い表示すると きなどはそれがネックになりレスポンス低下を招く可能性があります。 この場合、そのへんも考慮してDB設計らしからぬ設計を行う場合があ ります。たとえば、複数の項目をひとまとめにして、一つの可変項目に 納めてしまい、テーブルアクセス時の項目連結を抑えてることにより性 能を上げるとか。上記例ぐらいなら問題ないと思いますが1テーブルに 数千近くの項目数があるような設計になれば検討する事項といえるか と思います。(お使いの環境にもよると思いますが)  

yuzuru0024
質問者

お礼

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

その他の回答 (2)

  • yambejp
  • ベストアンサー率51% (3827/7415)
回答No.2

>効率がよくなるのでは? わけることによるメリットはほぼなく、命題の内容をみるかぎり 効率がさがることはあってもあがることはないように見受けられます。 ただ、心情的にわけて管理したいというのであれば、 この程度のオーバーヘッドは個人レベルで管理するDBにおいては 分けてもさほど問題になることはないと思います わける意義があるものとすればざっと思い付きでこんなのが挙がるかと ・1項目に2つ以上のデータを収集する必要があるもの ・逆に任意で入力するようなNULLが多発するようなもの ・履歴データを保持する必要があるもの ・頻繁に追加・更新がかかるような項目 ・検索につかわれないような無駄に大きなバイナリデータ ・項目によってそれを統括管理する人がことなる場合 また極度にアクセスが集中するような想定で カリカリにチューニングするのであれば 逆に分けた方がよいかもしれませんが、たいていその手のサイトは もっと別の部分でボトルネックがくるので、そこまでシビアに テーブルを管理することはないかもしれません。

yuzuru0024
質問者

お礼

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

  • t_ohta
  • ベストアンサー率38% (5241/13712)
回答No.1

認証用の基本情報とプロフィール情報を分けたりと、用途が違う(SELECTするタイミングが違う)場合はテーブルを分けておく方が、負荷などを考えた場合有効な方法だと思います。 必ずセットで使う情報の場合は分けることによって負荷をかけてしまう場合があるので、その場合は1つのテーブルにまとめるべきだと思います。

yuzuru0024
質問者

お礼

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

関連するQ&A