SQLはトップダウンで考える
以前、複雑なSQLをデチューンしていくというのを書きました。
■１.OLAP関数を使って一括処理するパターン
■２.誤差配賦額をファンクションを使って計算するパターン
■３.誤差配賦額をファンクション内でループして計算するパターン
■４.ワークテーブル（ループ）を用いてストアドプロシージャ内で計算するパターン
■５.GROUP BYを使わない完全にループで計算するパターン（未実装）
例題としていつも使っているのは、ぱっと聞いたときにSQLでしようと考える人が非常に少ない処理になるからです。つまり、このような処理では、■５ → ■４ → ■３ → ■２ → ■１の順で考えてる人が非常に多い。
SQLで処理しようとする人は、ストアドプロシージャにするかどうかは別にして、■１ → ■２ → ■３ → ■４ → ■５ の順で考えて行きます。■１で完結できれば良いのですが、SQLでの一括処理がどうしてもできなかったり、効率が悪かったり、「こんなの分からない！」とクレームが来ると、SQLが大きいまま残るようにデチューンしていきます。
これは私が普段行っているコーディング（設計）の思考順で、まさしく削り出すイメージです。ボトムアップで考えて行くオブジェクト指向言語とは逆になります。
実際の現場では■３ぐらいかな？
おそらく、メンテナンス要員のスキルなどの問題から、一般的な落としどころは■３ぐらいじゃないかなと思います。
では、■３に向かうとして、トップダウンで
■１ → ■２ → ■３
と考えたとすると、■１は最小のコーディング量で仕様書は項目一覧ぐらいしか書きようがありません。一番手数が少ないパターンから順に考えて行きますし、■１から■２へは流用できる部分も多く■３まで進んでも、大半は流用でき最小の手数になります。
しかし、ボトムアップで
■５ → ■４ → ■３
と考えたとすると、■５はコーディング量が最大で仕様書も大きくなります。■５から■４に変えると、コーディング量は減りますが、既に最大の工数を使った後です。流用する部分より捨てる部分の方が多いぐらい。■３に変えるときも同じく大量に捨て去ることになる。仕様書を書いていたら仕様書の変更量も半端な量ではないですし、仕様書を変更しなければ、後々、メンテナンスに与える悪影響は非常に大きくなります。結果的に大変な工数を浪費してしまいます。
ボトムアップの方が実際のプロジェクトでよく見るパターンですが、同じ落としどころに落ち着くまでに費やした工数は、トップダウンの数倍以上になります。
RDBMSを使いながら、「HAVING句を使ったことがない」というプロも存在するようですが、それでプロとして仕事をしているとしたら、■５のパターンでしか作れません。その場合、システムが小さくパフォーマンスの問題が起きなければ■５のままでも動きますが、パフォーマンスの問題が起きれば、大幅に変更を加えながら■４ → ■３ → ■２ → ■１と進んでいくことになります。■５から始めれば■１は非常に遠い。ボトムアップで考えると現実的にはたどり着かないでしょう。
その感覚で考えれば「そんなオタッキーで、トリッキーなコーディングをして何になるのか？」ってなるのは仕方ないでしょうね。現実に、■５から考えたら■１を目指すのは非常に無駄なのですから。
しかし、ボトムアップで考えているから無駄なのです。無駄と感じるのは、そもそも違う思想で作られたSQLに、自分が分かる範囲の思想を当てはめて考えている馬鹿げた勘違いによるものなのです。
何度も書いていますが、SQLの思想はトップダウンです。■１ → ■２ → ■３ → ■４ → ■５ の順で考える必要があります。トップダウンで考えるSQLの思想が分かっている人に取っては、■５はパフォーマンスは出ないし、チューニングし、現実的に使えるレベルに至るまでのとてつもない無駄が見えているから、馬鹿らしくなってしまうのです。
単に逆に考えているだけですが、では、同じように「SQLの思想で考える人はSQLの思想に凝り固まっているか？」というと違います。
■１から考えるレベルになれば自分なりの実行計画は持っていて、オプティマイザが出してくる実行計画と一致するか確認しています。実行計画というのは■５と同じになりますから、実は両方を考えているということになります。つまり、■５もできるけれど、オプティマイザが自動でプログラムしてくれるものを自分が一から書くのは無駄だから■１から入る。ということなのです……。
何にしても、RDBMSを使いながら「SQLなんて」という人は何も分かってないです。頭が固く自分の世界を抜けれてない。逆に考えてしまっています。
とにかく、SQLをやるなら「ボトムアップ」の考え方を「トップダウン」に変える。そこからスタートです。自分の世界を抜けないで、文法など余計なことを考えても身につかないし、今までのプログラム言語との違いを嘆いても仕方がない。まずはトップダウンのイメージを付けましょう。
