テーブル構築 
こんにちわ、かーつんです。
今回はDBのテーブル設計時の話し。
あくまで私の主観での話しなので間違ってるかも(苦笑)
まぁ、同僚と話してて意外と考えられていなかったので、書いてみます。
私はテーブルを大きく３つに分けて考えます。
更新系 と 参照系 と その他
運用上、更新が多いのか、参照が多いのか、
ざっくり分けちゃいます。
分けることで何が変わってくるのかというと、
インデックス です。
SELECT文を実行するときに条件として使用する項目インデックスをつける。
これは結構基本だと思います。(データ量との兼ね合いもありますが)
ただ、あまり考慮されてないのが、UPDATE文・DELETE文。
UPDATE文とDELETE文はインデックスが付加されているテーブルを更新する際、
インデックスも更新しにいきます。
要するに、処理に時間がかかりリクエストタイムが無駄にかかります。
なので、テーブルを更新系と参照系に分けて考え、
インデックスの量を調整する必要があるわけです。
ただ、構成上、参照も更新もどちらも頻繁に行われる場合があると思います。
それが、その他。
この場合は、参照を優先してインデックスを付加するようにします。
傾向として、登録更新に時間を要する処理は待って貰えるんですよね。
でも、参照に時間のかかるサイトって、やっぱり見て貰えないんです。
なので、純粋に参照が多いと思われるテーブルほどではありませんが、
参照を意識したインデックスの付加が必要になってきます。
参照メインのテーブルにインデックスが無いとか、
更新メインのテーブルなのにインデックスが大量に付加されているとか、
ナンセンスなわけです。
こんなこと書いてると、
「鯖スペック上げれば良いんだよ。」とか言われそうですが、
予算って決まってるんでそう簡単にもいかないんですよね。。。
あとは、たしかに回線速度や鯖スペックが上がってて、
意識する必要がなくなりつつあるのも事実かも知れませんが、
エンジニアとしてはその当りも考えておくべきかな。と。
もちろん後々用途が変わって調整ということもあります。
そのときには是非意識してみていただきたいです。
大量データの処理を行う際(ログの分析とか)には、
テーブル構成の善し悪しもありますが、違いが明確に現れるはずです。
会員数の増えてきたサイトでのユーザ検索とかでも有用なはずですよ。
更新なんかで言うと掲示板のスレッドとかネ。
とりあえず今回はここまで。でわまた次回(´･д･｀)ﾉ〃