RDBで最適なパフォーマンスを得るのは、経験と知識が要ります。
単純なテーブルで数千件程度のデータの場合は目だって差はでません。アナライザーを介さないと索引が働いているか否か判らないくらいです。
データ量が多いアプリケーション(人事給与など)で三次正規化されたTableが多く且つメインテーブルの行数が10万件以上のオーダーになったら、RDB設計者の手腕がシステムを左右します。
この手のTableは OuterJoinが連続することもあり、索引が使われなかったら、トンでもなく遅くなったりします。
(*) outer Joinの結果は 1件か0件になる筈で n件該当するのは、DB設計がオカシイと考えます。<= この結果 積JOINになって 10万件が 500万件になって慌ててたチームが身近に居ました...orz
日付をキーにするか、人Codeをキーにするかは業務如何でしょう。
数年分のデータを一つのTableに持つのも考え物です。年、月別にTableを作るのも手でしょうし、RDBの機能でTable分散という事も考えられます。
システム設計段階で、RDB設計者とアプリ設計者は協調して、システム作りを目指すべきです。
・先日相談を持ちかけられた件
大法人システムの一環の給与システムの開発で、RDB設計は既存のものを使い、集計(出力)部分を開発する。というもの。
そこで問題が発生。 "集計業務は1時間で終わる事"という業務要件があるそうな。
ところが、抽出SQLの実行が 3時間かかり、これが10種類あるので、計30時間かかる... バッチが1日で終わらない。
"一時間で終わる".要件を満たすのはプログラマの仕事だ。なんとしろと攻められている由。
妙案はないか? と相談されました。
言われてもねぇ。 "1時間で終わる" という要件は、システム全体としての問題なので、プログラマの範疇ではないと思います。
勿論、下手な作りで遅いのだったら責任はあるけれど。SELECT文が遅いようだし、join句に不穏な記述はないし。
私の結論は、「DB構造がまずそうなのでで、DB設計を見直してもらへ」なのですが、 大人の事情で、RDB部分は口出しできないんだそうです。
おかしくない? 上流工程のDB設計がまずいのを製造工程に責任転嫁している構図と思うのです。
ぐだぐだ言っても拉致があかないようだったので、「集計期間に合致する関連テーブルすべて、ローカル(メモリー上のDataTableやDisk.Table)に取り込み、
言語で Loopして集計したほうが早いかも。」とアドバイス(?)しました。
なんと20万件のデータをDataTableに読み込み、Outter結合の部分も言語でLoop処理して該当データをメモリー内で集計した由。
他の9種類の集計表も元データは同じなので、このDatatableから出力できるので、1本のJOBで 10種類対応できた由。
肝心の速度は 一時間30分まで縮まったので、納品物としてOKしてもらったそうな。
結果オーライかもしれませんが、腑に落ちない。単純な集計業務がSQL(SUM)より言語でLoopするほうが早いというのは。RDBの設計ミスな気がするのだが。
こんな絆創膏的なシステムって世の中に多いのだろうね?