データベースの正規化の話で、以前書きましたけど、正規化する、しない以前に、まずは、どういう場合に処理スピードが早くなったり、遅くなったりするのかの要因について、まとめてみようと思います（ただし、正規化に関係しそうなことのみ）
そして、そのあと（今日のブログではなく、気が向いたときに）で、それらの要因が、正規化と、どう関係しているのかを考えていきます。
＜＜DBで処理スピードがかかわってくる要因＞＞
いちおう、知っている話、噂話をまとめてみました。
まちがいもあるかも。。
■■（１）インデックスをつけると、検索は早くなる（更新は遅くなるときもある）
インデックスをつけると、検索は早くなります。もし、早くならなかったら、インデックスをつける人はいないでしょう。
問題は、更新のときです。
インデックスを更新する分、更新スピードは遅くなるはずです（無視できるほどかもしれないけど、理論上）。
とくに、インデックスの編成法によっては、すなわち、インデックスが、B木系（B木,B+木、B*木など）の場合は、場所によって、いろいろと遅くなるかもしれません。
それを防ぐには、インデックスをハッシュにするという手は、あることはあります。
ただし、ハッシュの場合、こんどは、キレイにデータが散ってくれないと、あるキーでは、遅くなるという結果になります（シノニムが多数発生するという状態になると、こうなる）。キレイにデータを散らせるには、インデックスのキーに偏りが無いことが必要となり、キーのある部分が、意味のあるコードを表すのはまずいということになります（キーのうち、サイズを示すところがあると、その部分はS,M,L以外は値がないといったような、偏りが出てしまう）
■■（２）SQL文のWhere句が長いと、処理スピードは遅くなる
そりゃ、条件ふえるから、条件すくないよりも、理論上長いよね。
ただ、実際どのくらい長くなるかは、そのDBMSやそのたもろもろ諸条件による。
これは、検索、更新どちらにもいえます。
■■（３）テーブルJOINが多いと、遅くなる
最近、そんなに遅くないやつもあるし、おそいやつもあるし。。いろいろ。
■■（４）中間テーブルを使われてしまうと遅くなる
SQL文によっては、中間的に、テーブルをつくることがある。
たとえば、having句をつかうようなものは、一回、どこかにためているからこそ、
そのhaving句の検索条件で検索できる。
で、この中間テーブルは（having句と書いたことからもわかるように）GROUP BY
とかすると、作るらしい（これ以外のときでも、そのDBMSが、中間テーブルを作った
ほうがいいと判断したときにつくるらしい）
これを作られると、そりゃー、メモリ領域を確保するわけですから、おそくなりますわな。
で、インデックスを作って、インデックスだけで操作できれば、このテーブルを
作らないらしい。
佐藤氏の流派で、GROUP BY禁止なのは、このためと言われている（と確か思った）。
■■（５）VIEWとスピード
検索のときは、単純に、selectでJoinしてから検索するよりか、はやくなることがおおい（作り方にも、もちろんよるけどね）
更新のときは。。。どーなんでしょう。
佐藤氏の流派では、VIEWを使うより、正規化して、インデックスを使うことによって、処理スピードは上がるとして、VIEWを禁止していると、確か思った。
■■（６）行連鎖・行移行など
これは、日経ビジネス構築２００５年１２月号１５７ページに説明が載っています。１行がながーい可変長レコードなんかを更新するとき、前の行に収まらないので、分割して格納したり（行連鎖）、別の、あいているところに、１行分格納してしまう（行移行）こと。こうすると、１行を取得するためのアクセス数が増えるので、遅くなる。
これ以外にも、SQLとトリガーの話など、いろいろあるんでしょうけど、正規化と関係しなさそうな話なので省略します。
というか、一般的に、処理スピードのサイトというと、「懸賞生活」じゃないよ、
おら！オラ！Oracle-どっぷり検証生活とか、その会社のサイトにある、Oracle SQL文テクニック集などが、中心となるのでしょうから、話は、そっちにゆずることにして、とりあえず、ここで、終わりにしておきます。
アクセス
トータル
ランキング
