人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

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

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

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

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

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

●質問者: dingding
●カテゴリ:インターネット ウェブ制作
✍キーワード:データ データベース ユニオン レコード 大丈夫
○ 状態 :終了
└ 回答数 : 1/1件

▽最新の回答へ

1 ● b-wind
●60ポイント

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

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

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

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


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

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

◎質問者からの返答

ありがとうございます。

大変参考になります。

select * from xxx

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

関連質問


●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ