テーブル設計について

質問

会員制の小さなサイトを運営しています。

会員は会員IDで管理しているのですが、テーブル設計が適切であるか判断できず、助言を頂きたく書き込みさせて頂きました。

現在、会員情報テーブル(info)というテーブルが全ての基本となっています。
このテーブルには、会員IDの他、名前や性別、住所、自己紹介文などほとんど全ての会員情報が含まれています。

このほかに会員同士の交流用のテーブル(koryu)がいくつかあり、
そこには、会員IDとその会員が行った内容が記録されています。

で、現状、交流用テーブルを使用する場合、常に会員の名前を会員情報テーブルから引っ張ってきており、これが、処理的に重いのでは無いか、と思っています。
以下はたとえばの例ですが、
　select koryu.id, info.name, koryu.contents from info,koryu where koryu.id=info.id
のように、毎回、（ほぼ）名前だけを引っ張ってきています。

引っかかっているのは、この「名前だけ」というところで、例えば、会員IDと名前しかないテーブルを作成すれば、もしかしたら、処理が軽くなるのでは・・と思っているのです。

２０カラムあるテーブルと関連付けを行う場合と、２カラムのテーブルと関連付けを行う場合、
２カラムのテーブルのほうが、処理は軽くなるのでしょうか？また、軽くなる場合、そうしたほうが良いのでしょうか？

（現在、１０００名くらいしか会員がいないため、処理が重いということは無いのですが、
安いサーバを使用しているため、処理はなるべく軽くしておきたいと思っています。）

よろしくお願いします。

回答No.1

SaKaKashi · ベストアンサー

テーブル結合の負荷は結合するテーブル間のカラム数の多少には関係ないです。
結合する項目が多い場合には影響しますが、参照しない項目の多い少ないは関係ないです。
ただ、あなたの場合、会員IDと名前だけの表を作るより、会員IDと名前で構成する複合キーを
索引として作成すれば検索は早くなる可能性があります。
会員IDで表を検索して、該当する名前をもう一度読むか、
会員IDと名前の索引を検索すればそこに名前がありますから検索すれば名前を読む必要がないのです。

が、索引は数が増えるほど更新や挿入が遅くなりますから注意が必要です。

お礼

>テーブル結合の負荷は結合するテーブル間のカラム数の多少には関係ないです

知りたい情報でした。
ありがとうございました。

回答No.2

hisappy

質問文の範囲からに対しての回答なので
実際のシステムで適応できかどうかは負荷次第ですが

交流用テーブルを使用する度に select 文を発行するのは
交流用テーブルの参照頻度によっては無駄に負荷がかかりそうですね。

「名前だけ」程度が頻繁なのなら、
交流用テーブルに名前カラムを追加してしまった方が
where 句もなくなり select 文もスッキリして
憶測値三分の一の負荷減少が期待できそうです。

この辺りは人間の手順と似たような感覚で
「アッチとコッチでコレ持ってきて～～」よりも
「コレのコレ」ってなってたほうが簡単な認識でよいのでは？

名前カラムが無茶苦茶デカくて
サーバの課金単位がデータの容量なら
不適合ですが。。。

お礼

>where 句もなくなり select 文もスッキリして
>憶測値三分の一の負荷減少が期待できそうです。

とても魅力的なのですが、会員情報で名前を変更した際にややこしいことになりそうなので、
今回はパスします。

返信、大変参考になりました。
ありがとうございました。