SQL私観

はい。負け犬の遠吠えです。

SQL。難しすぎです。

もちろん単体のテーブルをSelectしたり、2,3個のテーブルをJOINする分には難しいことなどなにもありません。しかし、ちょっと細かい選択をSQLで作りこもうとすると、大変です。まるでクイズ。つーか実際SQLで課題を解くクイズが、実際にありますよね（しかもかなりたくさん）。今仕事してんだよ。クイズ解いてる暇ねーんだよ。とちょっと野蛮な言葉遣いになってしまいましたが、SQLのクイズとか見ていると何でこんなに難しいんだ、と思います。つーかクイズが成り立つ言語ってどうよ？

難しい理由は何か。それはSQLだから。つまりSQLだから難しい。すなわち難しさはSQLの本質的な属性と言えましょう。（この辺、論理大丈夫かな）

あまりにも難しいがために、便宜的で安直な解釈／用法がまかり通り、今ではそれがほとんど常識となっています。つまりデータを正規化してテーブルに落とし、キーでJOINして、SELECTしてINSERTして・・・。実際には非常に複雑で非直感的な仕組みの上に成り立っているのですが、それをばっちり隠蔽してしまっている。

いや、結果的にそうならざるを得ないと思いますし、それが正しいと思うんですよ。正面からSQLを理解するのってもはや研究者の仕事としか思えません。

初心者が何となくJOINを使って実装してしまうと（何となく実装するな、というツッコミを貰いそうですが、そうならざるを得ないプロジェクトがいかに多いことか）、内部の動きが隠蔽されている分、やってみなければパフォーマンスに問題がないか分からない。いや、やってみても分からない。十分にデータを突っ込んで試さない限りは。すなわちパフォーマンスチューニングが非常に難しい（統計情報に依存／実行計画の確認が必要）のがSQLです。初心者がSQLを作りこめばそこにパフォーマンスのリスクが生じる。脅しや極論ではなく、プロジェクトを運営する人が身に染みている分かっていることだと思います。

Java、Cなどの言語に毒された発想かもしれませんが、少なくとも処理が逐次的に理解できる手続き的な解法の方が、パフォーマンスへの影響を見極めやすいなど、メリットが多いと思えます。しかし複雑なSQLで解こうとすると、実行計画を実際に見ない限りどうなっているのか分からないし、しかもそれも統計情報に依存するわけで。

初心者はJOIN原則禁止。副照会厳禁。別に恥じることはないですよ。これでいいんじゃないか、と私は思います。え？それじゃ学習しないって？やっぱりダメか。

以上
.