データベースの項目数の制限。


一つのレコードの項目数が例えば100こあったら、処理が遅くなるなどの弊害はあるのでしょうか?

2つのテーブルにわけてジョインやユニオンするよりも1つのテーブルでデータをもってしまうおかと考えていますが、項目が100くらいになりそうなので、大丈夫か気になります。

例えば、20項目のテーブルを5つジョインするよりも、1つのテーブルに100項目あるものを検索する方が早いんですよね?

また、1つのテーブルのうち100項目あっても、検索の仕方によって、一部しか使わないことがあります。
その場合、よく使う情報用のテーブル(例えば10項目)と、詳細用のテーブル(例えば全100項目中のid+残りの90項目)を分けて、詳細が必要な時はジョインするのがいいでしょうか?
もしくは、よう使い情報用テーブル(例えば10項目)と全データ用テーブル(例えば全100項目)を用意して使い分けたらいいのでしょうか?
はたまた、別に全部用だけでもそれほど処理に影響出ないのでしょうか?

回答の条件
  • 1人3回まで
  • 登録:2006/11/09 20:40:27
  • 終了:2006/11/09 21:21:43

回答(1件)

id:b-wind No.1

b-wind回答回数3344ベストアンサー獲得回数4402006/11/09 20:51:39

ポイント60pt

あくまで一般論として、まったく無いとは言えませんが通常 100 カラム程度であれば大抵のDBMSで問題ありません。

JOIN 処理にはインデックスを引いてデータを持ってくる処理とデータを結合する処理が入るので、大抵の場合コストが高くつきます。

データを参照する時に SELECT の後に必要なカラムのみ記述すれば、参照のコストも変わりません。

ただ、SELECT * FROM XXX; のように * で全カラム指定するとデータ量が多くなるのでちょっとだけ遅くなる可能性があります。


以前同じ考えをして詳細用テーブルを作った事がありますが、プログラミングが面倒になっただけでほとんど効果がありませんでした。

例外として、DBユーザによって参照するカラムを分ける場合はテーブルごと分ける形もありえますがパフォーマンスとは別の話です。

id:dingding

ありがとうございます。

大変参考になります。

select * from xxx

しないで必要なものだけ取り出せばあまり気にしなくてもいいんですね。

2006/11/09 20:57:43

コメントはまだありません

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません