久しぶりに更新 - SQLer 生島勘富のブログ

　昨日、SQLWorldの「みんなでSQLを書いてみよう」というハンズオンの企画の勉強会に参加した。

最初にお知らせ

　次回の企画のために、「実務で困っているSQL」を募集するそうです。
　「こんなのSQLで出来るの？」という問題があれば、コメントやメール info@g1sys.co.jp でご相談ください。

やっぱり、できた方が良いと思うよ

　私の興味はSQLとは全く違うところに向いたけれど（苦笑）SQLについて、これだけマシンが速くなったら、パフォーマンスはあんまり拘らなくても良いかなとも思っているのですが、それでもできた方が工数的にもメリットが大きいと実感した。

　特に、最後にやった問題は、実務ではもっとかなり複雑だけれど、その複雑な実務でもSQLで恐らく可能です。在庫とか、生産管理の山積み、山崩しなどの複雑な業務も、数個のSQLで可能ですが……。

　しかし、現実にはグリグリ回してやることになる。

　それが、保守し易いかというとそんなことはない。
　山積み、山崩しの仕様書なんて、私は、大抵読んでも意味が分からない（悪い意味で）。「数個のSQLで出来そうなことが、なぜ、この何百ページの仕様書になるのか？」と……。
　（テーブル定義も母言語でやり易い形になってるしね……）

　「SQLは使い回ししにくいから変更に弱い」というのは一面しか見てないのでしょう。数個のSQLで出来るなら、テーブル定義と項目移送表があれば十分で、仕様書は要らない。
　何百ページの仕様書と、キレイなオブジェクト指向で書かれたモノを直すのと、SQLを書き換えるのと比べたら、保守でも、トータルではSQLを直す方がはるかに楽。

　まあ、程度問題なんですけどね……。

なぜ難しいか？

　多分、出来ないことと、出来ることの判断がつかず、「出来ないことを悩み続けることになるんじゃないか？」という不安が先立つからだと思う。

　「もしかしたら、どうやってもできないかも知れないのに時間を使っている」という不安の裏返しで、「Javaや.Netなどの母言語でやれば、時間は掛かっても100％出来る」と心の中で思っています。

　そのとき、脳味噌の中で「母言語側のループで考える」思考ルーチンを使っています。ところが、SQLは全体を観て考えないと出来ないので、不安とプレッシャで「母言語だったら出来るのに」となったら、全く逆から考えていることになり答えは出ません。ちょっと不安になっただけで、袋小路に迷い込んでしまうのが、恐らく難しく感じさせる問題点なのでしょう。

　結果として、後から考えたら、「手掛かりもないまま、ただ、悩んでいた時間」となってしまって、「SQLなんてクソ」という印象が残るのではないかな？

　こんな風に、

　本当はもっと高い到達点があるけれど、ほとんどの人にとっては、恐怖の泥沼に突っ込むイメージに感じるはず。

　だから、もの凄く中途半端なところで諦めてしまって、プログラムソースは、SQLという言語と、母言語のスパゲッティになって切り離せないか、SQLを使わない方針しかなくなるのです。