SQLer 生島勘富 のブログ

RDB・SQLの話題を中心に情報発信をしています。

リモコンは指で押せ!

 SQLは大昔からあるメタプログラミングなのですが、メタプログラミングと呼ばれない理由は、自動生成されたコードが見えないからでしょうか。ベンダーにすればそれを見せてしまえばRDBMSの中身を見せているのと同じですし、見せる必要もないのでしょう。その代わりに、自動生成されたコードを「実行計画」として簡易出力するようになっています。これが曲者で、SQLを魔法だと思う馬鹿タレを量産してしまった原因だと思う。

 文法的に正しいSQLならば、どんなに長いSQLでもオプティマイズするときにアルゴリズムは自動生成されます。自動生成されるコードは数倍〜数十十数倍以上になりますから、SQLでできることにSQLを使わなかったら理論的には生産性が悪くなります。

 SQLのスキルが上がれば生産性は理論値に近づき、書く(実装)のも、読む(保守)のも、SQLの生産性を超えることは理論上できません。

 しかし、スキルがなければ最大無限大の時間が掛かるので比較になりません。できない人が絡んで来ると議論にはなり得ないのです。理論的な反論があればいいのですが、それはあなたがスキルがないからでしょう。としかいいようがないものばかりです。

例えば、LINQの記述がいいとか……。

 ざっくりいって少し語順が違うだけですが、なぜ、そんな細かな違いが気になるのか?それを変えたら分かるようになるなら、今のSQLのままでも書けるし、読めるでしょう。全く理解できない。

 そんなものは「慣れ」の問題でしかないです。

 どんな言語でも慣れた人から見れば簡単ですし、慣れない人から見れば訳が分からないものになる。それは自然言語でも同じで、日本語は世界中で最も複雑な言語の一つです。

 例えば、同じ漢字を扱う中国語は、英語とほぼ同じ語順で、一字の漢字は基本的に一つの読みしかありません。日本語では例えば「生」という漢字は11通りも読みがあり、日本語で最も読み方が多い字とされています。私の姓のような固有名詞を含めるともっと多くなってしまいます。しかし、中国語は方言ではイロイロ違いがあっても基本的に方言毎に一字一音で、北京語では「Sheng」だけです。また、中国語には活用もありません。同じ漢字を使う言語でも日本語の方が難しいとも言えます。

 しかし、その複雑な言語を操る日本人が、かなり簡単な言語の英語を苦にする(私もそうですが)。

 中国人からすると、日本語より英語の方が簡単という人も居ますし(どちらかと言うと多い)、英語に比べて漢字がある分、日本語の方が簡単という人も居ます。

 それは突き詰めれば「慣れ」だけの問題です。40年間日本語に慣れ親しんできた私に取っては、誰がなんといおうと日本語が一番簡単です。

 プログラム言語についても同じで「分かりやすい」というのは曖昧模糊とした基準でしかないでしょう。

 LINQが分かりやすいなんていうのは「感覚」の問題でしかなく「慣れ」の問題でしょう。人工言語の場合、難易度は記述量で量るしかない。

 SQLは動詞から始まる英語の命令文を目指していますから、少なくとも、LINQよりSQLの方が英語には近い。しかし、LINQは日本語の語順に近く、処理順に近いので、個人的にはLINQの方が分かりやすい。英語圏の人もLINQの方が分かりやすいという人が多いが、それも感覚の問題でしかない。

 システムの構造として、LINQ to SQLで内部的にSQLを使わないのなら話は別ですが、内部的にSQLをはき出すのですからほぼ無意味です。CSVXMLなどと同様に扱う必要があるのであれば、まあ、多少の意味はありますけど、位置づけとしてSQLよりも高級な言語になってしまうため、SQLでできることが完全にLINQではできず、パフォーマンスは悪くなってしまいます。

 パフォーマンスが悪くなる分、生産性が上がるかというと、記述量が変わらないということは理論上は生産性に大差はない。事実、慣れたらどっちでもほぼ一緒です(VSとの親和性はLINQの方が高いのでその差は多少出るけどね)。「CSVXMLなどと同様に扱う必要がある」という点がそんなに重要とは私には思えないのですが……。

例えば、O/Rマッパーが……。

 O/Rマッパーは極々簡単なSQLは自動生成する。O/Rマッパーは言語じゃないけれど、まあ、そう扱うとするならばSQLよりも高級ということにもなるが、法則通り、高級になればできることは限られるから極々簡単なSQLしか生成できないわけ。

 その極々簡単なSQLすら書けないのか……。SQL書いた方が早いがな……。

 やっていることは逐語訳で、SQLオプティマイズとは天と地ほどの差がある。話にならない。

 なぜそんなレベルの低い機械翻訳を入れるのか。O/RマッパーがSQLを使わずに、直接、データにアクセスするなら分かるけれど、間にSQLの様な高級言語(つまり、コンピュータから見れば非効率で、人間から見れば効率的)入れる意味はどこにあるのか?

 最終的には、何らかのマッピングは必要だから、マッピング機能としては使ったらいいと思うし使うけれど、SQLを書いたらいいがな。

リモコンは指で押せ!

 かつて、テレビにリモコンがなかった頃、チャンネルに棒を付けたりして操作している人も居た。しかし、当然リモコンができると棒なんて意味がなくなります。どうしても棒が手放せない頑固な人達はいませんでした。そんな非効率なことをする意味がないからです。

 SQLアルゴリズムがなくなりました。リモコンと同じように簡単になったのです。しかし、どうしてもアルゴリズムを考えたい人達(ボトムアップで考える人達)が棒を離さなかった。リモコンを使わないように元の手回しチャンネルに戻るのではなく、今度はリモコンを棒で押して、押しにくいと言ってる。逆に考えて棒を手放さないから押しにくいだけで「指で押せや!」ってことなのです。

 業務を効率化するために存在するシステム屋さんが「リモコンを棒で押す」という馬鹿げたことをいつまで続けるのか?

 棒が手放せないのはかわいそうだけれど、それが正しいと思い続けるのは何とも痛々しい。O/Rマッパーとか、LINQとか、SQLをなんとかラップしようとする技術は、詰まるところ、棒で押しやすくするためにリモコンの上に載せるものを開発しているってことで、そんなくだらんものを作るなら、SQLを使わない何かを作るか、SQLのスキルを上げればよい話。

 リモコンは進化しすぎると何を押していいのか分からなくなる(苦笑)。そのため、現在売られているテレビには、シンプルリモコンなんてものがオプションになっていたり、サードパーティから売ってたりする。しかし、決して「元からあるリモコンの上に何かを被せて棒で押しやすくする」みたいな馬鹿げた構造にはならない。常識的に考えて別のリモコンを作るでしょ。

 SQLRDBMS)は高機能になったので「そこまで要らない」っていう小さなシステムもあるし、どうしても単純かつ、高アクセスに耐えるという要件もある。そんなとき、なぜ、嫌いなSQLRDBMS)をラップして使い続けるのか?

 リモコンに何かをおっ被せる構造になるO/Rマッパーもおかしいし、リモコンを棒で押すのも非常に馬鹿げている。

 RDBMS(リモコン対応テレビ)を使うなら、リモコン(SQL)を棒で押さずにちゃんと使いなさい。リモコンが要らないなら昔のチャンネルのテレビを持ってきて棒で回せばいい。どうしてもリモコンが気に入らず、シンプルなリモコンが欲しいなら作ったら良い。

 繰り返すけれど、RDBMS(リモコン対応テレビ)を使うなら、リモコン(SQL)を指で押すべき。棒で押したり、ラップしたりするのはおかしいと言ってるだけです。
※ 汚れないようにするのじゃなく(苦笑)

 問題は馬鹿が多すぎて多数決で負けると、リモコンを棒で押す馬鹿げたことに付き合わなければならないから。

 多数決が正しかったらいまだに地球は平らのままです。技術者に多数決は関係ない。理論でひっくり返らないなら技術者を名乗るな。

普及してなかったら意味がない。

 おまけ。どんなにすばらしくても普及してなければ意味がない。私は現実論者なので普及してないものは基本的には無視します。普及してなければないのと同じです。

 今後の普及率を考えるなら、例えば大型書店を廻ってみたらいい。超大型書店でもCOBOLの入門書はほとんどおいてない。COBOLは技術者の人口としては、まだまだ、一定の割合はいるはずですが、今からCOBOLを覚えようとする人はいないからです。

 90年代後半なら、VB:SQL:C(++):Delphi:Java:(アセンブラFORTRANCOBOL)ぐらいの並び順だったか。その前なら、いくつか消えて、マイコンとか、dBaseなども入っていた。書店におけるコンピュータ関係の棚は小さかったけどね。

 現状では、SQLOracleSQLServer、他のRDBMSが合わさってDBコーナーは必ずある。他では、Javaコーナー、.NETコーナー、最近伸びてきているRubyは、PHPなどとひとまとめになってネット関連コーナー。他に伸びているのは、I-Phone、Androidなどのモバイル開発コーナーがあるかどうか。コーナーの分類別の大きさを調査すると、SQL系が最も大きい書店もある。

 書籍を求める人というのは、基本的に入門者が多いため、書籍の数は、数年以上先の趨勢と一致する。書店は売れない本は置かないので、極めて合理的なソーシャルフィルタリングができる場所です。特定の技術は、関連書籍が書店から姿を消す頃には仕事が激減して、その何年か後にほぼなくなるのだけれど……。例えば、VBは、2005年頃には書店では.NETに置き換わってほぼ消えている。仕事としては激減したけれど、まだ、VBを使っている所はたくさんある。COBOLの減り方もほぼ同じ。

 SQLが今のCOBOLの位置になるのはまだまだ先の話で、現在の状態では簡単には消えない。SQLは90年代から主役として普及して、今後もまだまだ消えないのですから、いい加減ちゃんと使おう。ってことなんですけどね。