kなんとかの日記 このページをアンテナに追加

2010-06-04

SQLが苦手なオブジェクト指向屋さん

| 10:11 |  SQLが苦手なオブジェクト指向屋さんを含むブックマーク

なんか炎上してるらしんだけど、なぜ炎上するのかわからない。ごく当たり前のことを言っているようにしか見えないのに、なぜあんなにアンチが湧くのか理解に苦しむ。ちっぽけなプライドの問題?


2.SQLオブジェクト指向言語の数十倍の効率

 オブジェクト指向言語を使い切るのと、全部staticで宣言してしまうような使い方と比べても、効率は数十%も変わらない。

 SQLオブジェクト指向言語を比べたら、数百〜数千%の差が付く。

炎上したのでまとめ:ベンチャー社長で技術者で:エンジニアライフ

まあ、そうだよね。SQLでできることはSQLでやったほうが高速 (例外もあるだろうけど少数)。

スクリプト言語Javaとの速度差なんて、下手なSQLひとつで吹っ飛んでしまう。そういうのを経験すると、SQLがいかに重要かが身に染みてわかるし、ほかにも「言語の速度 != アプリケーションの速度」というのは当たり前のこととして受け入れられる。でもSQL知らない人ほどそれが受けいれられない。

でも、SQL難しいわ。学習コストが高すぎる (だからこそ、マスターしたら武器になるんだけど)。


■ 何が問題か

 分業化すれば互いに専門家として尊重しあえるけれど、残念ながら分業化できない。分業化できない最大の理由は、オブジェクト指向言語が好きな人たち(技術者とは到底呼べない)が既得権を離さないから

 オブジェクト指向言語が気になって仕方がない。好きだし、新しいし。それは悪いことではないが、技術者側の都合でしかない。新しいモノの追求はしたらいいけれど、必要条件の効率にどれだけフィードバックできるかという観点がなければならない。

 つまり、SQLが古かろうと気に入らなかろうと、数百〜数千%の差が付くなら、まずそれをきっちりやるべき。新技術を取り入れるかどうかは、数百〜数千%以上の差が付くかどうかで検討すればいいけれど、残念ながらRDBMSを使うのに分業化していないうちは、そんなモノは存在しない。分業化できれば、SQLが比較対象から外れるので、更なる効率化の余地はいくらでもありますけどね。

(強調は筆者による)

既得権』という言葉が妥当かどうかはわからないけど、言いたいことはわかる。オブジェクト指向言語に詳しいのにSQLが苦手という人は多い。そして、そういう人はなぜかSQLができないくせに勉強しようとしない。実は逆もしかりで、SQLも業務知識もよくわかってるおじさんが、オブジェクト指向についていけてないことも多い。どっちもどっち。

分業については、O/Rマッパー次第としかいえない。

あと、「NoSQLが流行ればSQLを覚えなくて済む」と勘違いしている人もいるだろうけど、違うよね。SQL+RDBMSで難しかったことがNoSQLでは簡単に実現できたりするけど、逆にSQL+RDBMSで簡単にできたことがNoSQLでは難しかったりする。NoSQLは、SQLRDBMSとはまた違った難しさがあるから、勉強しなきゃいけない点ではいっしょだと思う。

efef 2010/06/04 19:38 そうそう
効率を判っていない奴ほど、効率って言うよね

SQLに効率を信託する奴は、次にセキュリティを信託する

適材適所


の議論じゃない

kwatchkwatch 2010/06/05 00:59 なんという意味不明のコメント・・・

tanotano 2010/06/08 21:38 kwatchさんの視点が好きなので、たまに読んでます。

> SQL難しいわ。学習コストが高すぎる

私はテーブル設計やDBパラメータのチューニングは難しいけど、SQLは覚える項目が少ないので、好き勝手にテーブルが作れる環境があれば、比較的、簡単ではないかと思ってます。

実際、フロントエンドにACCESS使って、SQL組んで帳票出してる御客さんもいるくらいだし。

逆にJavaなどは環境を含めて考えると、仕事に使えるようになるまでは、ハードル高い気がします。通常、SQLプログラマの多くは環境周りに手を出さないですが、Javaプログラマはプログラマ自身が、言語以外に難しいフレームワークと付き合う必要があります。

kwatchさんみたいに、いろんな言語に堪能な方がSQL難しいというのは、どのあたりが障害になっているか、「やだ、きょうみある〜」です。差し支えなければ、教えていただけないでしょうか。

あ、O/Rマッパーは頭痛いですが、これは言語としてのSQLとは違いますよね。

kwatchkwatch 2010/06/10 08:07 SQLは宣言的な言語なので内部処理がブラックボックスになっており、そのせいで挙動を追いかけることができず、思ったように動作しない時やチューニングしたいときにどこをどう直せばいいのかが非常にわかりづらいです。
これはHaskellなどでも同じことが言えると思います。本来、宣言的な言語は中身を詳しく知らなくても使えるはず(抽象度が高いため)のですが、実際には中身に精通しないと、デバッグやチューニングができません。そこに大きな壁を感じます。
これはちょうど、オブジェクト指向が簡単と感じるか難しいと感じるかによく似てると思います。クラスやメソッドの文法を覚えるだけならオブジェクト指向は簡単ですが、実際にはデザインパターンなどを身につける必要があり、そこが大きな壁になります。SQLも文法だけなら簡単でしょうけど、実際にはそれだけでは済まないですよね。