効率の山は複数回訪れる。
正規化の効率を考えてみる。
正規化は基本的な技術ですが、COBOLから抜けきれていないと正規化すると遅くなると感じる様になる。
これはおそらく私もだろうと思うけれど、効率をグラフ化して最初に訪れた山が最高と感じるものです。それはつまり、落ち始めたらそれ以上は危険と判断するからで、その先に進めなくなる人が非常に多い。
イメージとしてはこんな感じになります。
COBOLから始めた人は、最初に訪れる効率の山が全体としては極めて低くても、それが最高と判断してしまう。実際にCOBOLから始めた人が大半を占めるプロジェクトでは決して珍しくない光景です。
壁から先は見えてないから、COBOLからスタートした人達が見ているのはここまでです。その先は見えていません。
この曲線は、スポーツでも、勉強でも、何にでもあるものですが、いわゆる『壁』ってヤツです。最初に訪れた効率の山をくだるのは非常に怖く辛い。その先が見えてないと言うことは、やればやるほど深みにはまると感じます。その先には怖くて進めません。次に来る山は見えていないから、やればやるほど悪くなるとしか思えないのです。
しかし、COBOLをやってない人にとっては、正規化についての効率はこんな風に見えている。COBOLのような非正規化は最初からやってないから、そんなものは見てないし見れば馬鹿げていると感じるでしょう。
ここで面白い現象が起きます。両者の曲線の形状は同じで、いずれも「過ぎたるは及ばざるがごとし」「逆もまた真なり」という言葉が成り立ちます。ですから両者ともに「正規化はある程度すべき、しかし、やり過ぎると悪くなる」と同じことを言うことになります。
しかし、イメージしている曲線が全く別物のため、全くとんちんかんな話になっています。
例えば、ペーパードライバーに近いおばちゃんの中には、左足でブレーキを踏む人が結構います（こわーーー）。レーサーも（必要に応じてか、車が左足ブレーキ用の構造の場合）左足でブレーキを踏みます。それで、左足でブレーキを踏むおばちゃんが「でも、レーサーも左足でブレーキ踏むって言ってたわよ！私は運転巧いのよ！！」って言うのは、笑い話じゃなくって軽いホラーですね。
「正規化」でもそんなホラーに近い笑い話があるから、真面目にこんな http://www.doaplus.com/html/bun/bun03_20051101.html 実験までする人が出る訳です。
何事も乗り越えるまでは怖い。
正規化については、COBOLからスキルをスタートしても乗り越えた人が多い。乗り越えると、全部が見えていますから、「過ぎたるは及ばざるがごとし」といえど、効率のグラフが一本調子（山が一つ）でないことが理解できる人も多いでしょう。
SQLも同じ形のグラフになり、山も、谷（壁）も、何度か出てきます。
SQLもやり過ぎると下がるポイントというのはあるのですが、多くの人は最初の山しか見えていませんから、私が「確かにSQLでやらない方が良いこともあるよ」というのとは全く違うものを指しています。
つまり、そんなことをしたら効率が落ちる。という批判は、最初の谷を指していて、私はその先の山から下る部分を見て言ってるから、全く違うものを見ているので話が合ってないのです。
残念ながら、SQLは谷（壁）を乗り越えた人は少ないです。しかし、その理由は SQL が難しいからではなく「逃げ道がたくさんあるから」です。
正規化は逃げ道がないため長くやってれば間違いに気づきますから、いつかは乗り越えられます。しかし、他の言語を経験したことのある人は SQL は中々できない。一旦、下がる谷（壁）が見えたとき、どうしても逃げ道に走ってしまう。正規化なら他に逃げ道はないので、次の山を見ることによって乗り越えることができますが、逃げ道のたくさんあるSQLは、「イヤそんなことはない xxx でできる！」という次元の違うものを持ち出して逃げてしまいます。
最初の山で止まっている人は、谷（壁）を乗り越えたときの次の山の高さは見えてない。その時点では、無限に続く谷にしか見えないから怖くなって逃げますが、システムの規模によっては、逃げた先の方が遙かにキツイ地獄が待っています。
何度も例に挙げていますが、誤差配賦なんて訊いた瞬間にできて、書いて30分。それ以下なら最初の谷（壁）も越えてない。できない人の批判でしかないのです。
OO言語をどんなに駆使しても、RDBMSを使うなら（SQL をショートカットしない限り）内部的にはSQLを使っているのですからSQLを使いきってなし得る効率を超える方法はあり得ません。高いレベルのシステムを作ろうと思えば、SQLをより高いレベルで習得するか、RDBMSを使わないで、NoSQLを使うしかありません。
プロなら逃げるべきではありません。
