株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。

炎上したのでまとめ

»

 炎上したので、論点を整理しておく。

1.業務系では効率がトレードオフできない必要条件

 業務系の職務では、「効率を求めること」がトレードオフしてはいけない必要条件です(十分条件ではない)。医者でいうならば、「命・健康」と同じ、トレードオフしてはいけない必要条件です。

 効率が必要条件にならない職業もあるけれど混同してはいけない。

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

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

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

 言語や手法を考えるとき、慣れてない人はできないから無限大の工数が掛かる。ですから、できない人を対象に比べても意味がない。工数は最終的にはコーディング量比例するから、簡単に証明できるし、パフォーマンスも散々書いてきましたが、RDBMSを使う以上、SQLで処理することを超えることは基本的にない。

3.SQLとオブジェクト指向言語は分業すべき

 本来的には、スキルギャップが大きい技術を同じ人が担当することに無理があるので分業にすべき。現状では分業できてないので、全員がSQLをやるべき。初級シスアドのレベルを考えれば、全員ができてあたりまえ。

4.一般論に個別の事情は意味がない

◇    ◇    ◇    ◇

■ 何が問題か

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

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

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

 どういうわけか、「わたしが好き嫌いで話している」となるのですけれど、わたしに絡んでくる人たちは、絶対にトレードオフしてはいけない効率をトレードオフして「個人的な好み」を取っている。それで、既得権にしがみついて、いっぱしの技術者気取りで批判してくるわけです。

 わたしは理論値で話している。技術者として理論値を簡単に無視されたら、議論なんて成りたたない。

 多数決で言えば、RDBMSは最も普及している。SQLは初級シスアドに必須で出題されるぐらい、本来であれば最も普及している言語です。

 それでも、できない人(技術者とは到底呼べない)が多いだけ。その状況では、できない人に合わすよりも分業化して、お互いを尊重し合えるようにした方が効率的でしょう。早く既得権を離すべきです。

◇    ◇    ◇    ◇

 人間性について言いたければ言えばいい。ただ、そんなことは何も生まないので、ネチネチと絡まれても困る。2ちゃんねるでもチラシの裏でも、他所でやっていただければ。

 反論は1、2、3に対して、4を考慮しながら書いてください。

 申し訳ないし、大変残念なのですが、賛同していただける方にはコメントしません。コメントする価値がないと判断したものにもコメントしません。理由は、過去のエントリーのコメントをみれば分かると思います。あしからずご了承ください。

※編集部注:2010年5月20日16時40分、一部の適切でない表現を削除いたしました。

Comment(161)

コメント

Kenta

>わたしに絡んでくる人たちは、絶対にトレードオフしてはいけない効率をトレードオフして、「個人的な好み」を取っている。

だから違うって。
ほとんどの人が生島、あんたの人間性を批判してるんだよ。
逆に聞くが、誰が効率を否定してる?
人間性に問題があると感じれば直接批判するのが大人の役目だろ。
むしろおまえのように、自分の反対意見を汚い言葉で罵倒し、
ケーワイケー氏やAC/DC氏、小島氏のように
論についてではなく、人間性を問題にしている人をカスとかクズ扱いしておきながら、自分がカスとかクズとか罵倒しているのは効率を無視している人間だけとか嘘八百を並べ立てる、その腐りきった人間性こそ、2ちゃんねるのような便所にふさわしい。

ExtensionTsu

1.反論ありません
2.反論ありません
3.反論ありません

その上で言いたいのですが、私は「オブジェクト指向言語が好きな人たち(技術者とは到底呼べない)が既得権を離さないから」に猛烈な違和感を覚えますね。
まだ(地方では?)オブジェクト指向をわかっていない技術者は山ほどいると思います・・・
今回のコラムは「■ 何が問題か」から「◇    ◇    ◇    ◇」までは完全に蛇足だと思います。

それこそ、余計な蛇足をつけたために本来の趣旨を伝えるための「効率」を落としています。

無駄な喧嘩をしたいのであればそのまま続ければよいと思いますが、
それを嫌うのであれば、不要なコメントへの返答を控えるべきです。
私のこのコメントまで含めて、「反論になっていないのでコメントしません」と切って捨ててください。

Kenta

>>ExtensionTsuさん

違う。
生島が本来の自分の場所、
2ちゃんねるに戻れば良いだけの話だ。
向こうもきっとお前を待ってるぞ。

がる

がるです。
とりあえず気になったことを、簡単に。

> オブジェクト指向言語を使い切るのと、全部staticで宣言してしまうような使い方と比べても効率は数十%も変わらない。
> SQLとオブジェクト指向言語を比べたら、数百~数千%の差が付く。
それぞれ。「どんな観点で」「何をどのように数値化して」「どういうシチュエーション/条件下において」「どんな計測方法で」「どれ位の母数の調査があった上で」なのかがまったく書いていないので。数値が、厳密なものさしではなく「純粋かつ雑駁な主観」にしか見えないのは私だけでしょうか?
# 「私の経験上の感覚で」とかいわれても、おそらく多くの読者はそれで「あぁそうなんだ~」とはなりにくいように思われます。

> 工数は最終的にはコーディング量比例するから、簡単に証明できるし
設計にかかる工数も、コーディング量に比例するんですかね?
私は、時々「反比例する」ケースを見かけますが。

> パフォーマンスも散々書いてきましたが、RDBMSを使う以上、SQLで処理することを超えることは基本的にない。
RDBMSを使わない、という選択肢も最近出てきたように思われます。

> オブジェクト指向言語が好きな人たち(技術者とは到底呼べない)が既得権を離さないから。
なにか既得権があるのでしょうか?

> オブジェクト指向言語が気になって仕方がない。好きだし、新しいし。
-中略-
> SQLが古かろうと
SQL、厳密にはSQL86(ANSIによって最初に発表された最初の規約)が出されたのが1986年。
オブジェクト指向プログラミング言語として知られるSimulaが開発されたのが1962年(startが。発表は1967年)。
また、同じくオブジェクト指向プログラミング言語であるSmalltalkが出てきたのが1972年。
どちらがより新しくて、どちらがより古いでしょうか?

> 多数決で言えば、RDBMSは最も普及している
どんな母数に対してどんな調査をした結果として、なのでしょうか?
このあたりを明言されたいのであれば「統計学的に優位な調査結果」を出されたほうが、より信憑性が高いと思いますよ?


基本、私は一般論には興味がないのですが(おおむね不要であるというより、状況によって有害になることすら少なからずありえるので)。
とはいっても、一般論としてそも成り立っているのかどうか、が、私にはちょっと判じかねました。

がるさん、こんにちは。

何度か来られてますね。
私の記憶がただしければ、あなたはコンシューマ向けの仕事をされているのでは?

分野が違えば不毛な水掛け論にしかならないので、他所でやっていただければ。

Kenta

どうやら@itも汚い言葉賛同のようでw
http://twitter.com/Sikushima

>私が罵倒するのは、「効率だけじゃない」とか、「だってOO言語で統一したい」とか、技術者側の都合を一般論に持ち出したときだけなのですけど……。

よくここまで嘘つけるな~その面の皮の厚さにびっくり。
ギネスに申請したら?

ExtensionTsu さん、こんにちは。

代表的なので、オブジェクト指向言語って書いただけで、VB6だろうとCOBOLだろうと、RDBMSを永続化に使うなら同じです。

全部staticにしたって、配列を禁止にしたって、結果的には大した差はないのです。

Kenta

ぜひ小島氏やケーワイケー氏や俺がどこで、

>、「効率だけじゃない」とか、「だってOO言語で統一したい」とか、技術者側の都合を一般論に持ち出したときだけ

の発言をしたのか根拠を出してもらいたいなw

根拠のない発言が大好きな生島に根拠を求めても無理だろうがw

ぴあちゃん

敬称無しの名指しは止めません?知り合いならともかく・・・
せめて「さん」くらいつけましょうよ。

敬称なしの呼び捨て(書き殴り)時点で討論の資格剥奪されているの分かっていませんか?

kozawa

主観でものを主張するのがいけないことはないと思うのですが、
主観なら主観で、「何パーセントだと断言」せずに、正確に書くのが筋かと。

守秘義務もあるでしょうし、推測して書くと、
××のような性質(業務)のシステムで、
××のような規模の××のような環境で作った××に××ぐらいの
人数・工期がかかったけれども、これを××で作ったら××ぐらい
かかったと推測される、かな。

まぁ、上のようなことは今までに断片的に別々には書かれているとは
思いますので、改めて書く価値がどれほどかは・・・ですが、そのように
明記しておくと主張の妥当性はわかりやすいと思います。

私も数値は出せないので主観・経験値のみですが、
OO言語を使った場合に、社内業務システムに関しては、全部static
(インスタンス化ゼロ)で作ったからといって、そうでない場合より
生産性なり品質・保守性が著しく低くなったと感じたケースはあまり
多くないです。
#ただ、OO言語でインスタンス化を使ったからといって、
#その性質を使いこなせているプロジェクトがじゃあそもそもどれだけ
#あるのかが怪しいところでし、生かしていない故にOOの生産性優位を
#生かしきれていない多々ケースもあるかとは思いますがそれは余談

http://kmaebashi.com/
この辺のページを見ると、あちこちに分散しているので敢えてポイント
しませんが、「OO言語のメリットと呼ばれていることの多くはCでも
出来る。その中にはCのテクニックであまり知られていないものも含む」
ことが散見されます。

ただ、まぁこれもまたこれで、C++だってCで書けるわけで、これ自体は
極論ですが、本当に必要なら、その最小限のOO言語的なことをnon OO言語
でやることができないわけでもないですし(詳細は上記サイトを隅々
まで見ていただければと)、ケースバイケースで、static流でもやはり
OO的なもので必要なものがあれば技術で満たすことが出来る場合もあるわけで、
純粋に技術で閉じて言えば「OO言語で全部staticがどれほど悪か」は、
たったそれだけの短い命題ではほとんど議論不能で、善とも悪とも
言えない様な。。。
OO言語で、もちろんフレームワークの利用等でインスタンス化や継承が
必要になってくれば、当然「それ以外は全部staticに」なことをする
メリットは減ると思います。

別の例で言えば、Java+フレームワークでクラスのインスタンス化等々
利用して開発したプロジェクトで(正しく組んだならともかく)今回の
設計・実装するんだったらVBやCの方が良かった、と多数の人間が
感じてしまうようなケースも。

まともにデータがないなら数値的に優位云々言うな、という意見が
出ることは私にも理解できますが、ケースバイケースで「OO言語で
staticがさほど悪くない」のは別によくあることかな、と。
#ケースバイケースを言い出せば、SQL書かなくても、ともなりますが、
#それを言えばRDBMSにする必要もあるの?まで、色々と。

技術本位で言えばRDBMSにする必要のないシステムまで使ってないか?とか
DB設計がまともにできてなければそりゃ生産性落ちるだろ、とか
まぁ色々と。
結論ありきじゃなくて世間の誤解に物申すというレベルでは生島さんは
そんなに変なことを言われているとは思わないですね。
生島さんはそれなりには自分の主張の対象になるシステムについて
時々書かれてますし(単記事ずつだと見えにくいこともおおいような
気もしますが)。
#個別に異論があるとかないとかは別として

また別の例で、DBサーバ(RDBMS)とAPサーバが別で、DBサーバは他システムとの併用等の都合でリソースが著しく制限されていて、なるべく処理はAP側でしなければいけない場合・・・なるべく処理は業務側で、になりました。まぁ、思い切り特殊例ですね。

数値云々は、誰か研究してほしいなぁ。。。そういう研究をまともに
出来る機関ってあんまりないような気がします。日本の大学がやるには
一般論で言えば現場的すぎるし。

あと、別の余談で、「例外ケースを思い切り切り捨てて断言した方が(炎上するかもしれないが)主張がよく伝わって目的が果たせる」場合もあったりしますね。
生島さんが何を考えて書かれているのかわかりませんが。

ぴあちゃんさん(敬称付けにくい……)、こんにちは。

私は敬称にはこだわらないです。

小学生に「おっさん、こうちゃうの?」って言われても、
それが正しいと感じたら聞くし。

敬意を持ってないのに敬称を付けられても慇懃無礼ですよね。

flatline

私も純粋な好奇心から、既得権って何なのか知りたいです。

Kenta

>それが正しいと感じたら聞くし。

それが自分に都合がよければ聞くし。
の間違いだろ?

いろいろ、雑感。

こういう文章を書いていると、「当たり前のことしか書いてない」という
人が出る一方で、前提が抜けているとかいってくる人も出ます。

これね。技術者の猛烈な勘違いがあるの。

コンピュータはあらゆる前提を書いて上げなければ正しく動きません。
杓子定規に書かないといけない。場合によっては仕様書レベルで漏れが
あっては困ります。

しかし、人間は違いますね。人間に向かって書いている文章と、機械の
ために書く仕様書では性質は違うのです。

私は、ここでは人間に向かって書いていますから、普通の人間なら理解
できるはずと言う前提は無視しています。「当たり前のことしか書いてない」
という人が出るというということは、理解できる人はいるのですから、
それでよいのです。

アラを探して突っ込んですっきりしたいというなら、まぁ、それはそれで
結構な話ですけれど、そんな立派な技術者なら、一円の得にもならない
ここでやるよりも、実際の仕様書やプログラムの抜けを探して廻った方が
建設的ではないですかね~。

そういう行為は、自分はコンパイラレベルの杓子定規な人間だと宣言
しているのと同じでは?

evergreen

揶揄しているつもりはありませんので・・・

理論値で得をするはずのユーザーさえ説得できないから、
こんなところに怒りをぶつけているのではありませんか?

現実は、
あなたが最低とかくずとかいう人たちに頭を下げて仕事をせざるおえないわけです。
業務システムを作っている人は誰でも同じです。

「本当はこんなものいらない」
「本当はこんなのおかしい」
そう思いながら、食べるために仕事をせざるおえない。

たぶんOOP原理主義の人も同じジレンマを抱えているのだと思いますよ。

でも、理論だのスキルだのと考えているうちは何もかわらないでしょう。
資本や政治にはかなわない。

価値の大転換をしないと。
「良心的に」「正直に」に商売していることが価値にならなければ、
なにも変わらないと思いますよ。

歴史的にみても、まず理想があって、それを実現する技術(科学技術だけではありません)を開発するからイノベーションが起こるのですよ。
ビジネスなんかそのずっと後に生まれてくる話です。

redz

Kentaさん
生島さん
私の前回の発言でややこしくなってしまっていたら
申し訳ないです。
私が言いたかった事は
以下のような事です。

生島さん及び皆さんにお聞きしますが
必要十分なパフォーマンスが確保出来る場合に
過剰な実行効率を追求せずに
LLやORMを使って開発効率(これも効率ですよね?)
を高めたり、OOPによる抽象化で可読性や保守性を
求める事はいけない事なのでしょうか?

生産性が上がる事でリリースも
早くなりますし
保守性が上がる事で
拡張に対しても開けます。

これも技術者側の都合でしょうか?
過剰な効率重視も技術者側の都合では?

生島さんが気にいらないとしても
排他的になる必要は無いのではないでしょうか?

私は過剰にパフォーマンスを
追求するよりは生産性や保守性を重視するので
効率第一主義の生島さんとは
考え方は違いますが、生島さんの方針を
否定もしませんし理解もできます。
ただ単に違うスタンスと言うだけです。

私の場合は駆け出しの頃に
スパゲッティコードのメンテが多かったので
このような考え方になりましたが
バッチ処理のパフォーマンスで苦労する事が
多ければ生島さん寄りの考え方になっていたかも
しれません。

お互いに違う考えを尊重し合えば
良いのではないでしょうか?


また、新しい技術に対して懐疑的になれと言うのは
同意します。
私もEJB2.0で痛い目にあったのでw

はじめまして。

データの操作や定義を行うだけのSQLと、
オブジェクト指向言語が、何故比較されるのか判らないのですが、
いったいどういった場で比較されているのでしょうか?

どなたか教えていただけませんか?

ひまひま

初めまして。ひまひまと申します。SQLが重要以外賛同できません。
以下がその理由です。

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

オブジェクトはメモリの中にヒープ領域(クラスの実態の保持)とスタック領域(クラスの参照のアドレスポインタの保持)で成り立っています。使い切ったらシステムが止まります。効率どころではないです。

>>本来的には、スキルギャップが大きい技術を同じ人が担当することに無理があるので分業にすべき。現状では分業できてないので、全員がSQLをやるべき。

これは基本的に賛成です。ですがSQLを重点的に学習すればオブジェクト指向を軽視して良いという判断には賛成しかねます。コラムの中に出てきてますが、SQL言語を下手に扱うと業務に支障が出る分野です。だからこそSQLを複雑に記述しシステムを制御してはいけないのです。基本的にシステムの制御は言語側で行います。そのために大規模システムではAPサーバー(SQL部門専門のサーバー)を立てたり、小規模ではフレームワークやツール(O/Rマッピング)等で制御します。
これらを扱うにはオブジェクト指向への理解が必須です。

ひまひま

もうちょっとだけオブジェクトについて詳しく書きます。
分かり難いので二回に分けます

public Sugaku{
private int X;
public void SetA(int x,){this.tyoutenAX = x;}
}

実際の呼び出し
public static void main(string args){
Sugaku i = new Sugaku();
i.SetA(10);
}

ひまひま

続き

C言語の場合、
int i =10;
と書くと、メモリ領域に以下の様に記述されます。
00000000 0000000 0000000 0001010

次にオブジェクトの説明です、
Sugaku i = new Sugaku();
i.SetA(10);
を細かく解説します。

Sugaku i = new Sugaku();
と書くと、メモリ領域に以下の様に記述されます。
01010010 01001000 10010010 01001010 ※(スタック領域と言う)
これはC言語で言うポインタ(int *i)と同じです。
01010010 01001000 10010010 01001010 番のアドレスに
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 ※(ヒープ領域と言う)
と値を確保する領域を確保します。

i.SetA(10);

01010010 01001000 10010010 01001010 番のアドレスに
00001010 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
と値を格納します。

Static変数はスタック領域に値を確保することを指示します。
大量のアクセスがある箇所に使用したらシステムが落ちるのはそのためです。
以下がJAVAではありますが一般的に言われていることです。

・スタック領域
クラスのポインタアドレスを確保します。ただしプリミティブ型データ(基本型データ{int,long,double等})やStatic変数もこの領域に確保されます。

・ヒープ領域
 クラスの実態を保持します。(なお、構造体は含まれません。構造体はスタック領域に確保されます。)

皆さん、こんにちは。

勘違いがあるようですが、効率というのは工数とパフォーマンス両方を指しています。本文でもそうなっていると思いますが。

下手くそに書けばどんな言語でも無限大に無駄ですし、無限大に遅くなります。
比較はできる人で比較しないと意味ないのです。

RDBMSを使う以上、SQLをきっちり使い切った方が工数、パフォーマンスともに下がります。パフォーマンスはもういうのも馬鹿らしいので書かないけれど、RDBMSを使う以上、必ずSQLは必要です。

その単純なSQLの要素は、複雑なSQLに必ず含まれることになります。
複雑なSQLでは要素の重複はある程度避けれますが、単純なSQLではすべて書かざるを得ず、SQL文の合計だけでも、単純に書いた方が多くなります。

そこにSQLで可能なロジックがOO言語に必要になる。分割すればするほどロジック内のマッピング要素が増えますから、工数が増えるのです。これが理論値です。

SQLができない人に合わせることが正しいか?
正しいとしましょう。
じゃあ、OO言語をできない人に合わせることも正しくなりますね。

例えばの話、できる人どうしを比べれば、

非OO言語 < OO言語 30~50%
非OO言語 < SQL 140~1000%
OO言語 < SQL 200~2000%

となります。
どちらかを諦めるとしたら、効果で選ぶべきでしょう。

できない人がいるというのは技術者側の都合でしょう、技術者の都合で効果が大きい方をあきらめたらおかしいし、技術者の都合で効果が大きい方は見逃せても、効果の小さい方は滅多打ちにするって、どう考えてもおかしいのです。

技術者としては効率で選ぶべき。

会社としては、教育コストを考えて選択することはあろうかと思いますけれど……。

宝春

こんにちは。

ふむふむ、非OO言語よりもOO言語の方がSQLと比較した場合の工数(効率?)の差が大きいものなのですね。

ところですみませんが、私はOO言語がわからないので比較ができないのですが

(A).OO言語大好き。SQLは単文程度(あるいはぐちゃぐちゃ)。
(B).SQLは会話のペースでできて、OO言語もわかる。

こういった、(A)と(B)という人がいたとして、同じ要件の開発しようとした場合に
「(B)の人だったら、こうやって作るのに (A)の人は、このように作ってしまいがち」といった
簡単な事例をご紹介いただくことはできますでしょうか?
ソースまでとは言いませんが、見てみたいです。

いままで、この比較はなかったような・・・。(あったらごめんなさい)
お忙しいでしょうから無理ですよね・・・。

宝春 さん

済みません。

> 非OO言語 < OO言語 30~50%
> 非OO言語 < SQL 140~1000%
> OO言語 < SQL 200~2000%

非OO言語 & 単純なSQL をベースとすると
非OO言語 を OO言語 30~50%
非OO言語 & 複雑なSQL 140~1000%
OO言語 & 複雑なSQL 200~2000%

ですね。

何にしても、誰でも「普通」という認識は持っているものです。
得に宗教論争になりがちな好き嫌いが入るものは、誰もが「普通はこうする」というのを持っています。普通と思っていることは実際に普通かどうか分かりません。

できない人の例をいくら出しても、下手くそは、無限大の下手くそを作れるから意味がないのです。

技術者なら、MAXつまり理論値で測らないと、どこまで行っても水掛け論です。

職務の目的、理論値が重要なわけです。

do

ああ、なるほど。
「SQLとオブジェクト指向言語を比べたら、数百~数千%の差が付く。」
この数値は
>非OO言語 を OO言語 30~50%

>非OO言語 & 複雑なSQL 140~1000%
の比率でしたか。


ところで、疑問なんですが、宝春さんの例を多少改変しますが、
「OO言語は会話のペースでできるが、SQLは単文程度(あるいはぐちゃぐちゃ)」
なんて人はそうそういるんでしょうか(極稀にOOP原理主義者がいることは否定しませんが)

「どう頑張ってもSQLは単文程度」な人ではOOPも「まとも」には出来ないと思うんですが、その辺は実感としていかがですか?

宝春さん、doさん、こんばんは。

> 「OO言語は会話のペースでできるが、SQLは単文程度(あるいはぐちゃぐちゃ)」

大概、OO言語が(本当に)ちゃんとできる人は、やっぱり、効率をちゃんと見ていますから、SQLもちゃんとできる人が多いです。もちろん、できない人もいます。そういう問題は、結局、個別の問題になってしまいます。

技術者としては、理論値で測るしかないわけです。

繰り返しますが、非道い例(下手くその例)は無限に下手くそを作れるので、議論をするのは、理論値で議論しなければ技術者としてはおかしい。

理論値で測って差が大きい方を無視するなら、医者が癌より水虫を優先するのと同じです。

「理論値じゃない!」というのは技術者とは呼べない。

何というか、昔に書いたごく小さな例です。

http://www.g1sys.co.jp/column/_sql_2006_227_1.html

ストアドプロシージャで分業するならば、最初に聞いた人のイメージを超えるチャンスは数ヶ月になりますが、5~10分の問題というよりも、読んだ瞬間にSQLでできると考えなかったら、最終結果は回答例1か2になりますね。

素朴な疑問

生島さんにしつもーん。

現在のRDBMSそれ自体はほぼOOAなりOODで構築されているわけですが、それについてご感想は? それも否定されます?

AC/DC

とりあえず知りたいことが2つあるね。

まず、すでに何人かの人が書いてるけど、「SQLとオブジェクト指向言語を比べたら、数百~数千%の差が付く」とかの根拠はどこにあるのか知りたいね。具体的に理論値でね。

それから、OO言語な人たちの既得権って何かな?どんな既得権があるんだか、さっぱりわからんのだけどね。具体的に理論値で教えてくれるとうれしいね。

思うに、そのあたりが具体的な根拠も説明もなしに、いきなり飛び出してくるから、みんな戸惑うんじゃないかな。

AC/DC

あと、頼むから1日でコメント終了するのはやめようよ。

宝春

こんばんは。

> http://www.g1sys.co.jp/column/_sql_2006_227_1.html

んー、この例は以前も見ましたが、OO言語大好きな人は 解答例1 or 解答例2 になりがちということですかね???

私は80点でした。この設計を素直に書いてみたら3でした。
自分で要件から外部設計をした場合は、違う解答になったかもしれません。

ていうか、私は技術者としておかしいのか・・・。はっきり言われると傷つくものですね。
まぁ、たしかに理論値よりも感覚的に計ることが多いし、おかしいのかも。

Elpha

どうせ今回も汚い言葉で多数の「人間性」を罵りながらコメント欄閉じるんでしょ?

「人間性に言及する奴は人間のクズだ」みたいな

宝春

ごめんなさい。今回は最後にしますから許してください。

えーと、私は特に本分を無視したコメントばかりしてしまってすみません。
# いや、このスタイルは変えませんけど(笑)

ただ、ここはコメントがしやすくて、他の方とのコミュニケーション?も楽しんでいたのでやっぱり一日で閉じちゃうのは残念です。

あと、さきほどの生島様のコメントは、AC/DC様に対しておっしゃっているかと思いますが、今回AC/DC様は 今までと比べるとかなり柔らかい表現になっていたので、そこまでばっさりとやらなくても良いのではないかと思いました。

命題に対しては反論はありませんので、もう黙ります。
失礼しました。

# 私のメールアドレス、本名までご存知のはずですので、むかついたら晒しちゃってください><

>RDBMSを使ってSQLより効率(工数・パフォーマンス)で超える手法はない
いや、全くもってその通りです。
だって、それ(SQL)が真っ当な方法ですからね。
後からつけたものの方がかゆい所に手が届かない事は多いです。

>効率というのは工数とパフォーマンス両方を指しています
なるほど。

OOが力を発揮するのは再利用性と可読性と保守性だと私は思っているので、
そもそも同じ土俵で争う二つでは無いと思うのですが、如何でしょう。

別に一日で閉じるとか意味ないです。
コメント欄があっちこっちに行ってるから、整理してまとめるために閉じただけの話。

結局、新しい方に来てるのですけれど、明後日のコメントが多いのは困るね~。

AC/DC

あれ、それ、おいらへの返答?
質問に答えてもらえたのかな?
なんかはぐらかされたような気がするんだけどね。
まあ、答えられないってことで。

genek

こんばんは。

生島さんが仰っていることは、
「RDBMSを用いたシステムの場合、アプリケーション側で処理をするよりも、
RDBMS側で処理をした方が工数もパフォーマンスもいい」
ということだと解釈しています。

このことに関しては、私も賛成です。
ただ気になることが1つあります。

生島さんが仰る「理論値」とは、

>非OO言語 < OO言語 30~50%
>非OO言語 < SQL 140~1000%
>OO言語 < SQL 200~2000%

のことだと思うのですが、この値は理論値として最も重要な
ものが欠けています。
それは「導出過程」です。
理論値を技術的に検証することは、導出過程を検証することです。
決して比べっこするものではありません。
矛盾なく導出された理論値は、誰が何と言おうと正しいのです。
しかしこの値には導出過程がないため、理論値とは言えません。

ならば「実験値」かというと、そうでもありません。
それは「実験条件」がないからです。
実験値の検証で重要なことは、再現性です。
実験値と共に提示された実験条件で再実験し、同じ値が得られたならば、
その値は技術的に有効なものですが、その実験条件がありません。

理論値でも実験値でもないならば、残念ながら技術的には
あまり意味がある値ではありません。

技術的な議論をするためにも、上記の値の導出過程か実験条件を
教えて頂けないでしょうか?

do

回答ありがとうございます。

>大概、OO言語が(本当に)ちゃんとできる人は、やっぱり、効率をちゃんと見ていますから、SQLもちゃんとできる人が多いです。もちろん、できない人もいます。そういう問題は、結局、個別の問題になってしまいます。
その認識でしたら特に違和感ないです。
(それならなぜOOPに対してそれだけの敵意を持たれているのかはわかりませんが、きっと過去によほど酷い目に遭われたのでしょうと想像します)


あとはgenekさんのおっしゃるように数値の導出過程でしょうかね。
生島さんの体感上の数値であっても別に構わないのですが、その場合でも明記すべきことだと思います。

AC/DC

ああ、おいらが知りたいことが、genekさんが質問してることだよ。
ぜひ答えてもらいたいものだね。

ただ、doさん、
>生島さんの体感上の数値であっても別に構わないのですが
これは変だよ。
生島さんは「理論値」で話をしてるそうだから。体感上の数値とか、経験からのカンってのは、理論値じゃないからね。生島さんがそんな答えを返すわけないよ。

さあ、生島さん、みんなが答えを待ってるよ。
できたら、既得権についても知りたいんだけどね。

employee of G1

@ITの担当殿へ
ここも早く手を打たないと、みながわ氏より自己顕示欲が強い分、もっとひどいことになりますよ。

ちなみにここの馬鹿社長さん、何で毎回炎上するのか、少しは考えてみれば分かると思うのですがね。
まぁ、彼の人間性に興味は無いが、少なくとも自分の技術力の身の程もわきまえた方がいい。口は立つが、幅は狭く、底は浅い。

do

AC/DCさん

私としては論拠の裏づけさえ明確にしていただければいいのです。
そこさえはっきりすれば説得力については読む側が判断すれば済むので

うむ
> 生島さんが仰る「理論値」とは、
>
> >非OO言語 < OO言語 30~50%
> >非OO言語 < SQL 140~1000%
> >OO言語 < SQL 200~2000%
>
> のことだと思うのですが、この値は理論値として最も重要な

なぜ?意味が分からない。
例えばって書いているのにそれ理論値と違うがな。

個別の例外を上げても意味がないし、できない人の理屈を出しても意味がない。


何度も何度も書いているように、RDBMSを使う以上、SQLをきっちり使い切った方が工数、パフォーマンスともに下がります。パフォーマンスはもういうのも馬鹿らしいので書かないけれど、RDBMSを使う以上、必ずSQLは必要です。

その単純なSQLの要素は、複雑なSQLに必ず含まれることになります。
複雑なSQLでは要素の重複はある程度避けれますが、単純なSQLではすべて書かざるを得ず、SQL文の合計だけでも、単純に書いた方が多くなります。

そこにSQLで可能なロジックがOO言語に必要になる。分割すればするほどロジック内のマッピング要素が増えますから、工数が増えるのです。これが理論値です。

最終的な効率は、システムの規模によって違う。理論値は極小のもので考えるしかない。極小のもので大きな差が付くものは、理論値では絶対にひっくり返らない。

実際のシステムでは規模nのm乗(mは1以上)に比例するから、大きなシステムほど差が広がる。

OO言語がダメとか言ってない。
OO言語でstaticというのも、何度も何度も書いているけれど、理論値として確かに差が付くけれど、SQLから比べれば誤差でしかない。

いまだに言語解説しに来る人が現れたりするけれど、誤差に気を配るのであれば、もっと大きな差が出る部分に気を配るべき。

医者で言えば、水虫で癌の患者に、水虫から手を付けるのと同じ。

OO言語でstaticっていうのは、水虫の治療が下手くそなだけ。
癌の治療をほったらかしている連中が、「水虫の治療が下手くそ」って他人を攻めても意味がない。水虫の治療が上手いのは、それはそれで意味があるけれど、癌を前にしては意味がないと言ってる。

分業にすればいい。
分業制にすれば、OO言語の優れているところが存分に発揮され、OO言語の部分の再利用性は非常に上がるので、一部のエース級以外は要らなくなる。

本当に再利用性は高くなるので、一部のエースも常時は要らなくなるかも知れないけれど。お互いに専門性を高めないといけないので、OO言語でstaticなんて話にならない。

分業制ではなく、技術者がOO言語もSQLもやらねばならない現状ならば、まずは、全員がSQLに向かわないといけない。OO言語でstaticなんて誤差を気にしている場合じゃない。

us234

>非OO言語 < OO言語 30~50%
>非OO言語 < SQL 140~1000%
>OO言語 < SQL 200~2000%

この表現がよくわからないので確認させてください。
これって工数の話ですよね。

(非OO言語)&(単純なSQL)で開発した場合を100%とすると
A.(非OO言語⇒OO言語)&(単純なSQL)は工数30~50%
B.(非OO言語)&(単純なSQL⇒複雑なSQL)は140~1000%
C.(非OO言語⇒OO言語)&(単純なSQL⇒複雑なSQL)は200~2000%
ってことですか?
Aは工数減るけどBCは増えるってことですか?

us234さん、おはようございます。

最初のはまちがってたね。失礼しました。

(たとえば)例です。100%としているのではなくベースです。

OO言語にすれば30~50%効率(工数・パフォーマンス)が上がります。
※ OO言語の場合パフォーマンスは変わらないでしょうが

> C.(非OO言語⇒OO言語)&(単純なSQL⇒複雑なSQL)は200~2000%

200~2000%効率(工数・パフォーマンス)が上がるということです。


OO言語でstatic見たいな使い方は、確かに差があるけれど誤差でしかないと。
癌をほったらかして水虫の治療を言ってるだけと、何度も何度も書いている通りです。

理論値は、個別の事情が挟まらない極小のプログラムで差を見ればよい。
ソース量が倍になれば、工数は倍では済まない。ソース量nのm乗(mは1以上)に比例します。

us234

なるほど了解です。
ベースを100%として読んでました。

がる

がるです。

書かせていただいたのは
・数値化の根拠
・オブジェクト指向(プログラミング)とSQLとが、それぞれ出てきた年代
など、概ね「どんな分野の業務をしているのか」とは無関係なお話をさせていただいたと思うのですが。
それでも
> 分野が違えば不毛な水掛け論にしかならない
のですね。

大変に失礼をいたしました。

匿名

ひまひまさん

スタックとかヒープとかおっしゃってますが、どうもあなたの議論には、根拠となるWEBサイトとかがリンクされておらず、ご自身の検証とかを提示していただかないと納得がいきません。

staticがお嫌いなようですが、これもstatic関数が嫌いなのかstatic変数が嫌いなのかはっきりしません。

Javaやオブジェクト指向には都市伝説が多いようなので情報は鵜呑みにしないほうがいいですよ。
以下のリンクでは、メソッド関数って通常のC言語の関数と同じメモリの使われ方ようなことが述べられています。

http://oshiete.goo.ne.jp/qa/1797536.html

私が言いたいのは何度も何度も書いている通り、誤差で他人を追求するならば、十分な差が付く方をもっともっと気にすべき。

水虫の癌患者で考えればいい。

医者という括りにされている状態では、癌に目を向けない医者は、医者としての矜持がないカスでしょう。
癌を放置して、水虫の治療法で揉めるなんて、私の肉親が癌患者ならそんな医者は容赦しないし、同じ医者の立場でも許せない。
ちなみに、みながわさんは医者の括りに入ってない人で、立場の違う人の水虫の治療法に絡むぐらい立派なら、なぜ癌を放置するのか?と言ってる。


もちろん、これも何度も何度も書いているけれど、分業体制にになれば、皮膚科の医者が自分の仕事をほっぽらかして、癌のことを考えてもおかしい。
目一杯水虫の治療にこだわるべきですけれどね。

私の人間性について書きたいなら、どっか他所でやってくれたらいい。
彼らの目的が何にあるのか分からない。
そんなに嫌いな人間の人間性を変えてやろうとか思っているのだろうか?
だとしたら、大変ありがたい話だけれど、私の人間性は変わる分けがないからやめた方がいい。

でも、私の人間性が変わったら彼らに何のメリットがあるのかも理解ができない。

惚れられてるのかな~(笑)
女性だったら滅茶苦茶嬉しいけれど、野郎だったら正直迷惑(苦笑)

Kenta

人としておかしなことをしていたら批判されて当然。

で、理論値の根拠は?
人としておかしい上に、根拠もない発言たれながし?

匿名さん、ひまひまさん、おはようございます。

何度も何度も書いていますけれど、ここでは沿わないですよね。
言語解説なんて要らないのです。
それが悪いとは言わないけれど誤差なんです。

そんな細かいことが気になるなら、「もっと大きい方をちゃんと考えてくれ」って言うことを書いているわけで、どうでもよいことばかりを気にするのか?

私が自分の好きな方へと言われたこともあるけれど、小さい方しかみれてないですよね。水虫をどんなに治しても、抜本的な治療にならないって。

oumi

久しぶりでコメント(感想)を。


気になったのは、「SQLはオブジェクト指向言語の数十倍の効率」という事。
これって問題点、つまり「数十倍の効率」が出る部位はいった何?おそらく、
A)データの永続化の効率
B)データストアの操作効率
C)データの集合としての設計など
だと考えられます。このような「効率」が業務と開発そのものの効率へ結びつくという事。
RDBMSは当然ながら、A,B,C他に最適化されるように発展してきたのですから、現状、効率がよいのは当たり前。
そして、「業務系」(Line of Buissiness というよりは、もう少し範囲を狭めた基幹系業務を言っているニュアンスに感じる)ですから、必然的に(歴史的に)データストア(プール)ありきでの話になります。

しかし、であるからこそ、「オブジェクト指向言語の」が気になります。

理解している方は多いと思いますが、あえて書かせていただくと。
C)オブジェクト指向は、データの永続化を云々するものでは無い。
 そもそも、データにある種の責任を付与するという考えの上に成り立っているから。
D)一般的に、オブジェクト指向言語は、汎用言語でありSQLのような専用言語では無い。


まず、(C)について考慮されずに記事を書いたとすれば、これは無知としか言いようが無い。さすがにそれはない。
次に(D)を踏まえて書いたのであれば、当然であるが、比較すること事態が稚拙だと感じた。
そもそも、汎用言語というのはデータの操作や永続化を効率化するための言語では無い。

とは言え、「オブジェクト指向」という抽象的な単語は、これで括って論点を暈しながら話すにはもってこいである。なぜなら、読み手が勝手に色々に解釈しやすいからである。
まず、ものの解った技術者であれば、このような比較をあえて声高に言うとは考えにくい。(もちろん読み手がどうしようもない野菜だらけだと思って書くなら別である)
また、単純に単語に反応するということ(人)も少ないだろう。


とすれば、OOPの理解が厳密さがどうであれ、比較の厳密さがどうであれ、過去記事からの流れを踏まえて「SQL知らないのが多すぎるのは問題だ」等の延長で読むべきで、妙に細部をつつく必要もないし、妙に釣られる必要は無いのではないか?
(良い専用言語があるのに、なんで知ろうとしないわけ?それはまずいだろ?っていう感じの流れ。)


と考えると、「ず~~っと言っている趣旨は変わらない」というのは間違いない。


生島氏が言う「オブジェクト指向」では、純粋なオブジェクト指向という【事】【物】よりは、OOもよく知らん、SQLもよく知らん、で物をえらそうに作っている(言っている)人が扱う「偽オブジェクト指向絶対論?(なんじゃそりゃw)」を指している事も多い。
また、オブジェクト指向言語で製作されたオブジェクト指向では無いアーキテクチャー(例えばO/Rマッパ)を指す場合もある。
これはひっかかりやすい、オブジェクト指向として思わず括ってしまいそうになる。
実際、世の中には、OO言語で製作したら=OO指向である、と広義に捉えすぎる技術者も多い。
「知らない間に、OO指向で作ってるのです」とか、アホである。(もちろんプロモーションとしては有り!)

・DB使えますよね?使ったことありますよね?
・あります。
・どう使いました?
・普通にSQL発行するライブラリを使ってアクセスしました。
・チーン

と似たようなレベルである・・・
さすがに、ここにはそのようなレベルの人はいないと思うが・・・


気をつけないと釣られる。


で、ここのところの「人間性」・・・
人間性云々で釣られた人たちは、きっと純粋かつ想像力のすばらしい人が多いのね。
かす・クズ書いただけで、人間性を想像しちゃうって、すごいなぁ・・・
人と相対して「おまえの人間性は」なんていわないのに、なんでテキストだと言えるのかな・・・不思議。

いずれにしても、読んで、色々と考えられるネタ投下ありがとうみなさん。


という感想です。

flatline

AC/DCさん、genekさんが書いている通り、「理論値で話している」というのなら、「SQLはオブジェクト指向言語の数十倍の効率」という大前提の根拠を、説明してほしいですね。

でないと、AC/DCさんの『みながわさんが考えるところの「インスタンス」と「static」って何?』という質問に、ついにまともに答えなかったみながわさんと同じレベルでしか読んでもらえないと思いますよ。

oumiさん、こんにちは。

これまた何度も書いている通り、仕様書は機械のための文章。これは人間に向けて書いている文章ですから、いちいち前提を書きません。
ほとんどの人は理解していますから問題ないです。

デファクトだからOO言語って書いていますけれど、OO言語に限らず何だっていいのです。RDBMSを利用する以上、SQLを十分に利用しなければ非効率である。ってことだけなのです。

それで、デファクトのOO言語を考えても、日常的に『できない人に合わす』ということが行われています。SQLについても同じです。

OO言語の『できない人に合わす』は、こういう所で書くと問題になります。
SQLの『できるようになれ』も問題になるわけです。

それが逆だろう?ということしか書いてないのですけどね。

日常的に『できない人に合わす』ということが行われるのは、いずれの分野でもおかしい。プロとして『できない人に合わす』をなくすべきでしょう。

データ(永続性)に関するモノをできる限り汎用言語でやろうとするのも間違いですし、DB側で全部できた方がよいと、汎用言語の分野まで拡張するのも良くない(パーソナルなRDBMSとは呼べないAccessは例外として)

きっちり線引きをして分業体制を組むべきで、その線引きは多数決でOO言語側に寄りすぎ。

ですから、何度も何度も書いていますが、全部ストアドプロシージャにすれば、汎用言語側は
  パラメータを渡すこと
  ダンプ出力
  UI
を受け持つことになりますが、これらはいわゆるFWの機能をフル活用して工数を下げることができます。

ただ、下がりすぎてSQLを書けない技術者はほとんど要らなくなる。
FWを作るぐらい楽勝!ってOO言語ができる本物の技術者以外はSQLへ移行するしかない。

でも、業界全体として、雇用調整中だからちょうど良いと思うのですけどね。
本物だけがのこって、お互い尊重し合える環境になればよいと考えています。

genek

こんにちは。

生島さんのご意見の大部分は私も賛成です。
>RDBMSを使う以上、SQLをきっちり使い切った方が工数、
>パフォーマンスともに下がります。
とか、
>技術者がOO言語もSQLもやらねばならない現状ならば、
>まずは、全員がSQLに向かわないといけない。
などは、まったく異論はありません。
「青汁飲んだら健康になるんだから、みんな牛乳ばっかり飲んでないで、
青汁も飲もうよ!!」
ってなもんで、そりゃそうだと思っています。

私が何故その値が気になったかというと、
>非OO言語 < OO言語 30~50%
>非OO言語 < SQL 140~1000%
>OO言語 < SQL 200~2000%
ってすごいことですよね。SQLをがんばれば効率が2000%も上がるなんて。
「例えば青汁飲んだら癌も治るよ!!」
って言ってるくらい画期的なことですよね。
なので、その2000%効率をアップさせた状況を詳しく知りたかったからです。

しかしその回答が、
>なぜ?意味が分からない。
>例えばって書いているのにそれ理論値と違うがな。
となるということは、
「あくまで例え話だから、癌が治るとは限らないよ。イメージイメージ。」
ってことでしょうか?
だとしたら非常に残念です。

となると私としては、
 ・実際問題としてSQLをきっちり使い切ると、どの程度の
  工数の削減と処理速度の向上が図れるのだろうか?
といったことが気になります。
まあデータベースの種類や処理、ハードウェアやネットワークのスペック等が
絡んでくるので、正確な値は出せないでしょうが。
OO言語化による工数削減が誤差になるぐらい効率化できるんでしょうか?

エントリーポート

genekさん、こんにちは。

・Order by 使ってますか?
・Group by 使ってますか?
・分析関数 使ってますか?

SQLでデータ取得 + ループ(言語問わず)で処理
なんてしてたら、大概が工数も上がるし、
パフォーマンスも悪くなりますよね。

という話しかしてないと思うのですが。

flatline

あほか?さん

みながわさんが答えられなかったのは、OO知識がゼロに限りなく近い人だったからでしょう。
AC/DCさんにOOの知識がないと判断したのがどこだったのか知りませんが、ここではどうでもいいことですね。
私は、AC/DCさん、genekさんが知りたがっている質問の答えを、私も知りたいと考えただけです。
あなたは知りたくないんですか?

Kenta

本物しか残れなかったらまず生島、お前が残れないけどいいの?

で、偉そうに数字出してるんだから、根拠を出しなさいw

Kenta

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

と断言してるんだから根拠を出さないとw
論理的な考え方が出来るなら、当然根拠も出せるよねw

flatline

>たとえ、OO知識がなくても、インスタンスとstatic なんて、WEBで調べれば書いてあることでしょ。

そうですね。では、なぜみながわさんは「それすら」しなかったんでしょうね。
「インスタンスはどこでもドア!」なんて意味不明のつぶやきで多くの人の失笑を買ってたんですが。

AC/DCさんの質問の意図は、別にインスタンスとstaticについて知りたかったわけではなく、「みながわさんが」どう考えているかを知りたかったんだと思いますよ。

genek

エントリーポートさん、こんにちは。

すみません。私の認識が間違っていたのかもしれません。
>非OO言語 < OO言語 30~50%
>非OO言語 < SQL 140~1000%
>OO言語 < SQL 200~2000%
でいうところの各用語の定義は、

・非OO言語:非OO言語で記述したプログラム、SQL部分は関係するテーブルの
 全データを取得するだけ
・OO言語:OO言語で記述したプログラム、SQL部分は関係するテーブルの
 全データを取得するだけ
・SQL:プログラム側はストアドプロシージャを呼び出すのみ、RDBMS側で
 処理を行い、結果を返す

ということでしょうか?

あほか?

flatline さん

>AC/DCさんの質問の意図は、別にインスタンスとstaticについて知りたかったわけではなく、
>「みながわさんが」どう考えているかを知りたかったんだと思いますよ。

だからWEBサイトや本に書かれていることしか思いつかなかったからじゃないですか。インスタンスとstaticについて自分独自の考え方なんてもってなかったからだと思いますよ。そういう状況を読み取れないようじゃ生島さんとは勝負できませんよ。他の強力なコメンテーターに任せなさい。

flatline

別に勝負するつもりはないですよ。したいとも思いません。勝ち負けという低レベルなことに拘泥しているほど暇ではないので。
単に質問の答えが知りたいだけですよ。

エントリーポート

genekさん、こんにちは。

はい、その認識です。
というか、その前提でなければ、パフォーマンスに
そこまで差がつくとは考えられないので。
もし違うなら、私もその方法が聞きたいです。

エントリーポートさん、genekさん、こんにちは。

2000%は、対象が、非OO言語(OO言語でstatic)のような非道いものをベースにしていますので大きく書いています。
例えばのイメージです。

OO言語派は反対するけれど、OO言語の良さ(FWの再利用性・生産性の高さ)を考えると、ストアドプロシージャ & O/Rマッパ でやれば2000%も可能かでしょうけれど、現実は、打ち合わせとか、ドキュメントの何チャラとかのオーバーヘッドの方が目立って大きくなるので達成できない。

オーバーヘッドを除いたら達成可能な数字です。

OO言語や、O/Rマッパの良さは、ストアドプロシージャで分離開発したときに100%発揮できる。

ただ、発揮できすぎてOO言語側の技術者が要らなくなるのが難点。そこそこのFWを使えば新人君で十分になる。

ONEOUTS

失礼します。

いままでさんざん、「技術者なら理論値で語れ!」とぶちあげておいて、ご自分が根拠を問われると「例えばのイメージです」って何なのでしょうか。
「例えばのイメージ」が生島さんの言う理論値ですか?
そんないいかげんな言葉遊びを「理論」と呼ぶとは。きっと生島さんの作るシステムは「バグではない。仕様だ」というのがたくさんあるんでしょうね。想像がつきます。

Visual Studioが提供するクラスを使ってDBにアクセスすれば、SQLなんかをシコシコ書くより、数十倍から数百倍の効率とパフォーマンスが得られます。
え?根拠?
それは私の経験から得たカンですよ。

ついでに、次に生島さんの取る行動を予測してみましょう。

1.「日本語能力低すぎ、わかる人にはわかっている、前提はわざわざ書いてない」
と罵倒する。
2.「カスの相手は疲れる」と言って、コメント終了にする。
3.何事もなかったかのように、新しいエントリーをあげて、理論値への質問自体なかったことにする。

自分が論じている理論の根拠すらまともに数値化できないなんて。
技術者としては相手にするに値しない方だったのですね。

IPとメールアドレスさらしますか?

anekdoten

やっとネタ明かししたね。最初から前提条件についてきちんと説明すれば、醜態晒すこともなかったのに。

でも、言ってることって単なるトートロジーだよね。
『SQLが絶対的に早い条件下ならSQLが早い』
そんなのわかってるし当たり前すぎるしさ。みんな分かりすぎるくらい分かってるよ? 大事なことなので2回言ってみたけどさ、そんなの敢えて論じる価値なんてないんだよ。その程度のことをそれ以上にフカしてれば、まあ炎上するよね?

でも当たり前のこと言っても相手されないからね。
いい意味でも悪い意味でも注目集めたし、そういう意味では成功なのかな?

>これは人間に向けて書いている文章ですから、いちいち前提を書きません。
>ほとんどの人は理解していますから問題ないです。

これだけ炎上したのはその前提が誰にも伝わってなかったからだよね。自分の説明能力のなさを他人に責任転嫁するのは見苦しいよ?

anakdoten

>OO言語や、O/Rマッパの良さは、ストアドプロシージャで分離開発したときに100%発揮できる。

>ただ、発揮できすぎてOO言語側の技術者が要らなくなるのが難点。そこそこのFW>を使えば新人君で十分になる。

データ構造考えて、正規化崩して、実行経路考えて… そういう低レベルの仕事をSQL+DBで隠蔽してくれるならそれに越したことはないよね。汚いものが見えなくて、OOでビジネスロジックとUIだけ書けばすむならそんなにいい話はないよ。

来週のアップになったので。

導出過程

==
RDBMSを使う以上、SQLをきっちり使い切った方が工数、パフォーマンスともに下がります。パフォーマンスはもういうのも馬鹿らしいので書かないけれど、RDBMSを使う以上、必ずSQLは必要です。

その単純なSQLの要素は、複雑なSQLに必ず含まれることになります。
複雑なSQLでは要素の重複はある程度避けれますが、単純なSQLではすべて書かざるを得ず、SQL文の合計だけでも、単純に書いた方が多くなります。

そこにSQLで可能なロジックがOO言語に必要になる。分割すればするほどロジック内のマッピング要素が増えますから、工数が増えるのです。これが理論値です。
==


工数 = コーディング量 ^ n

nは1以上、ドキュメントと人数によって可変。

コーディング量のn乗となりリニアよりきつく増加し、規模によって数倍にも数十倍にもなる。

繰り返しますが、RDBMSを使っていて、SQLでできるものを他の言語で実現しようとすると、必ず、コーディング量は増え、パフォーマンスは落ちます。
コーディング量が下がれば理論的に工数は下がります。

以上は理論値。

前回のコメントに、以下に書いたのは、例えば……例え。


現実は

工数 = コーディング量 ^ n × 個別の事情


個別の事情には
  メンバーのスキル
  これまでの蓄積
  ユーザの要望
  システムの性質
  ツールのでき
  ・・・・・・

できないメンバーがいれば、個別の事情 = ∞ つまり、工数も無限大。
そんな個別の事情は、個別の議論しかできない。

ただし、議論の対象になっているものは、RDBMSは導入済みで使うか使わないかの差でしかない。使わない、使えない理由「個別の事情」の大半は「メンバーのスキル」「嫌いだから」それを乗り越えれば、他の事情ではひっくり返らない差が付く。技術者都合は、倫理的には理論値に差がないときにしかいってはいけない。

OO言語でstatic は「メンバーのスキル」は許せないわけでしょうが。
そんなのが流行ったら困るのでしょうが。
しかし、理論値でも現実にも有為な差は付かない。(慣れで補える)

SQLを選択しないことは、結果から言えばOO言語でstaticより罪が重い。

あ~り~

前回のコラムで私のコメントに返信がなかったのは
コメントする価値がなかったのでしょう。

まぁ、本コラムの内容に対する前提に一言
未だにこの「効率」が開発orユーザーの視点がわからない。
両方から見てる?いや必ずしも比例しないでしょう。
そりゃ、イニシャルが極大でランニング時が快適な状況は
線引きしますが・・・
・・・やっぱりコメントする価値がないのでしょうかね、私は。。

それはさておき、コラムとコメントを読んで・・・
そもそもの元コラムであった「static」は、あれはまぁ理解度など
様々な理由により残念ですが、その辺は捨てて、システムが停止してしまう
状況が発生するリスクがあまりにも少ないという、システムは稼動するんだ!
ということを前提としていればstaticでもよいでしょう。
拡大解釈な話として、ユーザー数10人、月3000件とユーザー数1000人、月100万件の
購買データを扱うシステムを同じとはあまり考えられませんし。(インスピで理解して・・・)
そんな同じ状況を想定してのコメントが少ないような・・・
まぁ、前提がわからんと言われればそれまでですがね。

さらに、SQLとOOなんで比較?とか・・・
比較にならないよ!って訴えているのですよね?
でも比較されるから訴えているのだと思います。

ちょっと個別に1点だけ・・・
anekdotenさん
>『SQLが絶対的に早い条件下ならSQLが早い』
>そんなのわかってるし当たり前すぎるしさ
去年末頃のコラムだったろうか・・・そんな前提の状態でも
炎上しましたよ。
OOなら~とかSQLなら~とか。
そもそも、RDBMSを利用している状況の『大部分は』当たり前の
状態にあると思います。
このコラムはその状況下においての話であると思います。
ついでに、RDBMSを使わない選択肢がでたら次元も変わるため
議論できません。

どうでもいいですが・・・
メアドはともかく、IPもわかっちゃうんですね。。。驚きでした。
@ITからコラムニストにはコメント欄記入するときの内容だけが
伝わるものだと思っていた・・・

ONEOUTS

はあ、とため息が出てしまいます。

>工数 = コーディング量 ^ n

これが生島さんの理論値なのでしょうか?
「これが理論値です」って、理論値の意味がわかっているのでしょうか。

>他の事情ではひっくり返らない差が付く。

ですから、「差が付く」根拠を「理論的に」書いていただけないでしょうか。

そんなのは常識だ
普通の人にはわかる

それは理論でも導出過程でもありません。

技術者を名乗るなら、数値でお話しましょう。

>SQLでできるものを他の言語で実現しようとすると、必ず、コーディング量は増え

生島さんのご意見はわかりました。
コーディング量が必ず増えるという根拠はなんでしょうか?
技術者らしく、数値でお話していただけないでしょうか。

素朴な疑問

私の質問は華麗にスルーされましたが、まあそれは我慢しましょう。

生島勘富さんは何か著書をお持ちでしょうか?

技術的バックグラウンドの確かさを証明するために出版されることをお勧めします。

ここでコラムニスト気取りもいいですが、いまどき商業出版はなかなか厳しいので、ブログの書きちらかし(本記事を含む)では太刀打ちできないシビアな世界ですよ。
その上で、ご説の正しさを証明すべきです。
@ITの編集に相談してみてはいかがでしょう?

@ITの担当者も、ここまでこじれさせておいて放置ってのは、あんまりじゃないですかね。まあ、楽しませていただいたんで、どうでもいいですけど。
いずれにしても、吠えっぱなしは損だと思います。老婆心ながら、御社社員の皆様の今後が心配になってしまいますので。

genek

生島さん、エントリーポートさん、こんばんは。

私の理解としては、データの通信量は同じで、データ取得以降UIまでの処理を
なるべくSQLにやらせると、パフォーマンスに2000%もの差が出るというものでした。

私の理解が間違っていたようです。申し訳ございません。

確認したいのですが、この場合パフォーマンスの差は、
通信時間の差が支配的になりますよね。
そして、処理結果を求めるためにアクセスする必要があるデータ量が
多ければ多いほど、差は広がっていく。

例えば10,000件のデータにアクセスして1件のデータを取得する処理の場合、
1回の通信に一律で1msかかるとすると、通信時間だけで
  SQL:1ms(ストアドプロシージャ1発)
  OO言語/非OO言語:1ms×10,000件=10s(全データ取得)
の差が出る。

これをもってSQLを使うと200~2000%効率を上げることができると言っていた、
ということでよろしいでしょうか?

MO

初めてコメントさせていただきます。

SQLとOOで差が付く根拠となる理論値が出てくるのを待っておりましたが、
生島さんの回答は回答になっておりませんので
ちょっと書かせていただきます。

「SQLとOOで差が付く根拠となる理論値」として書くならば

・SQLのプロフェッショナルがSQLで作り上げる場合の生産性がXXX程度
・OOのプロフェッショナルがOOで作り上げる場合の生産性がOOO程度
・よってSQLはOOの@@@倍程度、生産性が高い

・また、OOOな条件のデータ抽出(母数XXX件、対象@@@件)の場合、
 SQLのプロフェッショナルがSQLで作り上げる場合は***秒程度、
 OOのプロフェッショナルがOOで作り上げる場合は\\\秒程度かかる。
・よってSQLはOOの???倍程度、実行速度が速い

といった内容でも書かないと回答になりませんね。
このあたり、実際にどうなのか興味がある部分ですので
是非回答していただきたいところです。

それから気になった点をもう一つ。

>個別の事情には
>  メンバーのスキル
>  これまでの蓄積
>  ユーザの要望
>  システムの性質
>  ツールのでき
>  ・・・・・・
と書かれていました。

「メンバーのスキル」に関してはそうだと思いますが、
「これまでの蓄積」、「ユーザの要望」、「システムの性質」などは
ツール/言語選定の重要な要件になります。
ですので「個別の事情」ではなく「一般的な条件」だと思いますが。
これらを無視してのツール/言語選定はあり得ませんし、
あくまでも「理論」にしかならず、実業務的な話にはなりえないと思います。

いかがでしょうか。

AC/DC

一晩おいておくと、見事に発酵してるね。
理論値についての明確な定義は、いまだになされてないね。

効率について、ケイワイケーさんが書いてるね。
http://el.jibun.atmarkit.co.jp/ityuutu/2010/05/post-bb97.html

あと、生島さんの行動予測、吹いたよ、ONEOUTSさん。
どれもありそうだね。

このエントリーもコメント書き込み不可が近いかな。

みなさん、おはようございます。

まず、コメントに対する前提。
みなさん、あるいは宛名が書いてないものは、これまでの記述に対するものに対して、返しているもので、「俺はそんなこと言ってない」と言われても知りません。

特定宛名の方に返していないときは、以前のエントリーのコメントまでさかのぼってお考えください。(一つのコメントにすべての前提なんて書けるわけがない)

例えば、oumiさんのコメントにあるとおり、SQLは汎用言語ではないので、それを比較対象としている時点で、SQLでやるべきの意味は、普通の技術者は単純なSQL(O/Rマッパで隠蔽するのも含め)を使うか、複雑なSQLで一括処理をすることを指していると、わかるはずです。分からないというなら、あなたとはどこまで行っても理解し合えない。ここでコメントのやりとりをしても、お互いに何も生まないので、もうやめにしてください。

理論値について、どんな言語でやっても、コーディング量が個別の事情を排除する最低のラインです。

それ以外は、個別の事情が最も大きなウェートになるので、個別の議論にしかなり得ない。私が見たことのない、みなさんの個々の個別の事情を出されても議論にはなり得ません。

ですから、基本的には私の考える多いパターンを一般論として語ることになります。
みなさんが考える個別の事情と違うと思えば、それはご自身で考えてください。
それでは意味がないと思われる方は、読まなければいい。
個別の事情を出してへこましたい。と思うのなら、お互いに何も生みませんからどうか他所でやってください。

私は神ではないので、個別の事情を出されても分かりません。

何度か書いていますが、OO言語を出しているのは現在のデファクトスタンダードだから、OO言語に限らず、RDBMSを使うならSQLを使うべきとごく当たり前のことしか書いていません。

RDBMSを使うとき、SQLでできることを他の言語で行えば、理論値として必ず工数が掛かり、パフォーマンスが悪くなる。理論値として超えることはない。

数字では、単純なもので50%~100%、複雑なもの400%の差になります。
http://www.g1sys.co.jp/seminar090515.html

コーディング量のn乗の差は必ず付きますので、規模が大きくなればなるほど差が広がります。(理論値)

工数 = コーディング量 ^ n × 個別の事情

規模が大きくなればなるほど、できる人を集められない。つまり、個別の事情が無限大になるから、工数が無限大になりできなくなる。(現実)

例にある 200~2000% の低い方は妥当な数字ですけれど、上は、巨大なPJで会話のペースでSQLが書ける人が何十人か居たらという、現実的にはあり得ない数字になります。理論値ですからね。まぁ、私が十人いたらでっかいPJが終わるかっていったらケンカになってこれまた終わらないしね(苦笑)。


現実の論は、すべてに個別の事情が挟まるので如何様にも解釈できます。

例えば、2人月で作成して2時間かかるものを、1時間全部書き直して、処理時間を2秒にしたこともあります。工数だけでも40000%以上ですけれど、対象が非道かったらナントでも言える。そんな個別の問題を巻き込んでも何の意味もないでしょう。

動かないコンピュータもありますから、それを直せば無限大なのです。


理論値で考えれば、最後はコーディング量に行き着きます。

例えば、みながわさんの論ではコーディング量に大きな差は付かないのです。(理論値)
これは、若い人には分からないかも知れませんが、50代まで現役でいる人は、全部staticで書けば会話のペースで書けてしまいます。
(その社内では、そういう文化ですから保守も早いです)

SQLも突き詰めれば会話のペースで書けてしまいます。
会話のペースで書けるというのは、理論値に近づくわけです。
  「保守できなくなる」も保守要員のスキルという個別の事情。
  止まるかも知れない。もハード環境、要件による個別の事情。
  スケールアウトできない。もハード環境、要件による個別の事情。


みながわさんに人格攻撃しかなかったのか?私は人格攻撃できるほどの人格者ではないので、そこは無視して読んでませんが、「正しいOO言語の使い方」をふっかけていった人がいなかったとは言えません。
むしろ、大勢いました。

そういう人たちに書いているのですが「正しいOO言語の使い方」を押しつける人たちは、みながわさんの個別の事情は一切考慮してない訳です。みながわさんが、個別の事情をコメントしても、そんなの関係ないとかいう人もいたような気がします。

私は「正しいSQLの使い方をすべき」と一貫して書いています。
一般的な「技術者が揃わない」という「個別の事情」があることは十分に承知していますが、揃う会社もあります。個別の事情を考慮しなかったら、当然、「正しいSQLの使い方をすべき」になります。

みながわさんの「個別の事情」は無視し大した効果も見込めないのに攻めて、私には「個別の事情」で論戦を張ってくるのは、技術者としての資質についてダブルスタンダードで許せないと言ってます。人格は会ったことがないので知らないけれど、理論値でもなく「SQLはできない人が多い(もしかしたら自身が苦手)」という商業技術者が持ち出すべきでない「個別の事情」を乗せて議論に臨むのであれば、技術者じゃないわ(XXX)ってなるわけです。

理論値には意味がないのかというとあります。

理論値はスキルの向上やツールで埋めた後の行き着く限界です。

私は低い方の限界をキャップとするより、高い方の限界を設定して教育を行い、ツールを作っていくべきだと考えています。

O/Rマッパは、できない人が多い、つまり無限大を避けるという現実を見たものですが、「できるように教育すればいい」という当たり前から逃げた結果です。

理論値から、限界が高い方を選ぶ人が増えれば、教育方法ももっとブラッシュアップされるはずですし、ツールも向上していくでしょう。

だから、私は戦う。


他人に技術論をふっかけていくほど向上心も技術も持っているなら、低い方を選ぶなよ。

私がイライラしながらも1年以上も続けているのは、十分に向上心があるのに低い方を選んでいる人が多すぎるからです。

IDEも、FWも、行き着くところまで行ってるから、それを追求しても差は付かないよ。

ひまひま

はっきり否定されましたので、かなり厳しく書かせていただきます。
2番についてはWebサーバーを構築したりセキュリティーを考える立場(=プロジェクトマネージャーやリーダークラス)から考えると最低の内容です。
以下、GoogleGuice(googleAppi)上でデータを利用する際の問題点のVideo内容です。

http://www.youtube.com/watch?v=8RGhT-YySDY
(Staticを使用した場合の問題は3分位からです)

言っておきますが、GuiceだろうがSQLだろうがDB系(GuiceはDBとはちょっと違うからこうしました)からデータを利用することに違いはありません。
貴方は業務系のエンジニアとおっしゃっていました。
業務系は効率を優先するならセキュリティーを犠牲にして良いのですか?
SQLを知っていれば、WebサーバーやGuiceからの警告は無視できるんですか?
そしてこれらは数十%の誤差として考えて良いのですか?
馬鹿も休み休み言ってください。
前に貴方はおっしゃいました「Havingすらわからない奴が技術者なのるな」と
同じことを言わせてもらいます。「Staticすら分からない奴がWeb(特にサーバーややアプリ)に関わるな」

最後に貴方は戦わなくて良いです。間違った知識を世に広めるためなら。

AC/DC

生島さん、相変わらずわかってないね。

生島さんが「理論値」って言ってるものには、何ら根拠がないよね。

生島さん「数字では、単純なもので50%~100%、複雑なもの400%の差になります。」
大多数「へえ、でもその数字の根拠は?」

ってなるわけ。

それはチープな新興宗教の教祖が「私を信じて財産を寄付すれば死んだとき天国に行けるぞよ」ってのと一緒なんだよ。
だから導出過程なり算出根拠なりを出してね、ってみんなお願いしてるわけさ。

たとえば生島さんが人格者で、たいていの人が「この人の言うことなら信じてみてもいいかな」って思えるような技術者だったら、細かい根拠なんかは、とりあえずなくてもいいかもしれないよ。
でも生島さんは、明らかにそうじゃない。まあ、人をカスだとかクズだとか言ってるんだから、人格だけで信頼してもらえないのは自業自得さね。
生島さんは人間性について軽視してるみたいだけど、何かを広めようというときには、意外に重要なんだよ?

だから自分の教義を広めたいと考えてるんなら、まず理論値とやらの根拠を上げてみてくれないかな?

あとさ、使いもしないでO/Rマッパーを批判してるけど、いまどきO/Rマッパーが生成するSQLをそのまま使うなんてことやってるまともな技術者はいないよ。主キーで取ってくるとか単純なやつは別だけどね。O/Rマッパーだって、外部SQL書けるようになってるのはたくさんあるのさ。

AC/DC

訂正

いまどきO/Rマッパーが生成するSQLをそのまま使うなんてことやってるまともな技術者はいないよ。
 ↓
いまどき、まともな技術者なら、O/Rマッパーが生成するSQLをそのまま使うなんてことやってないよ。

ひまひま

AC/DCさん
・・・お前は一生Ruby(Rails)に関わるな。

生島勘富さん
一人のIT系のエンジニアとしてコラムや返答内容に文句を言わせてもらいます。
技術者が技術を批判はしては良いが馬鹿にするようなことは決して言うべきではない。
それぞれの技術には考え方や基づく経験及び知識があるんです。
IT業界はホリエモンみたいな人は少数です。
大抵の方は外人でも日本人でも職人気質の人が多い。
職人に向かって「俺の車は安全装置はないけど速いから素晴らしい。お前の車は安全装置なんか付けてるから遅くて出来損ないだ。」とこのコラムは言っているようなものだ。
こういうことを言う人をどう思います?
尊敬できますか? 一緒に仕事できますか?

Google Scholarにこんな言葉が表示されます。
「巨人の肩の上に立つ」
技術者(肩の上に立つ者)はこの言葉に代表される様に先人(巨人)の努力の上に技術や価値観を身につけます。
先人の努力や理由を知らずに勝手に決め付けて、価値観や技術を馬鹿にするべきではない。それは技術者として卑劣な行為です。

最後に『批判』とは、人やものごとの誤っている部分、よくない部分を論理的に(根拠を示して)『指摘』しその改善を求めることです。

あ~り~

AC/DCさん
年末のコラムのとき、O/Rマッパー信者がうようよ居ましたよ。

AC/DC

一応言っておくと別にO/Rマッパーを擁護しているわけでも何でもないよ。
使いもしないで批判するなってこと。

ヤス

レーシングチームがあるとします。
ある技術、ここではAというエンジンがあるとします。
いまのつんでいるBというエンジンをAに積み替えるとラップタイムが最低10秒縮まるとします。そのうえBを使える知識があればほぼAを積むのには支障がないとします。
Aを積まない理由が財政的なものやその他もろもろの要因ならば仕方ない。
しかし、Bを積まない理由がエンジニアの「いや俺はAのことよく知らないから」とか「Aが好きじゃないから」っていうのはプロとしてどうでしょうか?
俺はレースに勝つマシンを作るのが仕事なのに、それを果たすための行動をしていない。うましかといわれても仕方がない、って俺は思いますけど。
いや、Aを使わないでもBを使ってAより速く出来ればそれでいいんですが……。


あと、職人だからこそお互いの技術をぶつけ合ってより高い場所を目指すのが筋だと思いますけどね。技術について語り合い、その結果罵倒されようが、ぶん殴られようが、正論で叩きのめされてプライドがずたずたにされようが、自分自身が一生一品と思えるものに近づきたい。そのためにも学び続けないし、技術を盗み続けたい。向こうが間違っていると思うんだったら、それを論破できるだけのものを自分のものにしたい。言葉ではなくて作ったもので語れるようになりたい。
職人って言うのはそういうものだと俺は思っているんですけどね。
そして、そういう技術者に俺はなりたい。

MO

結局、回答をいただける気配がないので
この書き込みで終わりにしますが。

生島さんがこのコラム、及びコメントで書かれているのは
「SQLは効率がいい。だから大事なんだ。」という一点です。
具体的に何と比べてどうなのかという根拠は無い。
また、純粋なコーディングの生産性と実行速度だけのお話に終始されています。
これだけなら新入社員に言ってやる程度の内容ですね。

私は、RDBMSを使うのであれば
どの言語/ツール環境を選ぶにしろ
SQLは大事だと思っています。
自分自身、最上級とは言わないまでも
それなりのレベルではあると思います。

ですから、実業務に多少なりとも応用が利くような話を期待しておりましたが
「理論値」と仰られる根拠も出てこない。
本来、言語/ツールなどの環境選定の最低限の要件部分を
「個別の事情」と仰られて無視される。

コラム/コメントの内容は「実務家」のお話ではなく
「研究者」「哲学者」のお話のような感じです。

これでは実業務に役立つものは何もありません。
言語/ツールなどの選定に使えるような根拠にできる数値が無い。
また、「個別の事情」と仰られている部分は
ほとんどのプロジェクトで環境選定の必須要件となる部分ですので
その部分を抜きに話はできません。

私は「実務者」として現実に対処する必要があり、
理想の数字だけを追いかけられる立場ではありませんので。

以上、長くなりましたが、最初のコメントの意図/目的、
得られた内容くらいは書いて終わりにした方が良いと思いましたので
書かせていただきました。

あ~り~

AC/DCさん
失礼しました。
私の認識違いだったようですね。

abc

> MO 2010年5月22日 (土) 23:47
> 生島さんがこのコラム、及びコメントで書かれているのは
> 「SQLは効率がいい。だから大事なんだ。」という一点です。
> 具体的に何と比べてどうなのかという根拠は無い。

だって、彼ってそれしか知らないんだもん。視野が狭いんだよ。
議論していても、知らないことはすぐにはぐらかして、必ず無理やり自分の土俵(SQL(笑))に引きづり込む。だから、いつも議論が発散する。

あと彼のプライドが、知らないことを認めたくないし、自分が知らないことを知っている人間に対するリスペクトが出来ない。これじゃ、毎度炎上するわな。

子牛

abcさん、「知るを知るとなし、知らざるを知らずとなす、これ知るなり」ってやつですね!

abc

> 子牛 2010年5月23日 (日) 14:56
> abcさん、「知るを知るとなし、知らざるを知らずとなす、これ知るなり」ってやつですね!

おっ、そんなことわざがあるんですか?私は知りませんでした(^^;)。まさに、その通りだと思います。

この業界は、やたら知識をひけらかし、知らない人間を馬鹿にする連中が多いように見えますが、技術者とって大事なことは、知識の多寡ではありません。
知らないことは全く恥ではなく、今日知らないことは、明日知れば良いだけのことですから。
技術者にとって恥ずかしいことは、自分が何を知っていて、何を知らないかを自覚しないこと。知らないことを謙虚に取り込める度量が無いこと。その知識の根底に流れる思想を理解していないこと。

オブジェクト指向にしろ、SQLにしろ、現在は重要技術であることは明白ですが、10年後に役にたつ知識かどうかは分かりません(特にSQLは怪しいね)。
我々の業界に関する知識なんて、そんなものばっかです。これで一度天狗になってしまったら、技術者はそれで終わりでしょうね。

子牛

ことわざというか、... 論語です。他に有名なところでは「無知の知」というものもありますね。ソクラテスです。たぶん中学か高校で誰もが学んでいるはずですが、忘れてしまった方々も多いようですね。あ、これも知識をひけらかしたことになっちゃいますかね。まあ人は忘れる動物ですので、お気になさらずに。忘れてしまったことは全く恥ではなく、今日忘れてしまったことは、明日思い出せばよいだけのことですから。技術論に限らず、日々是勉強を絶やさない謙虚な姿勢が重要ですね。色即是空、空即是色、南無阿弥陀仏。

abc

> 子牛 2010年5月23日 (日) 17:12
>たぶん中学か高校で誰もが学んでいるはずですが、忘れてしまった方々も多いようですね。
> まあ人は忘れる動物ですので、お気になさらずに。忘れてしまったことは全く恥ではなく、今日忘れてしまったことは、明日思い出せばよいだけのことですから。

おっと、これは一本取られましたね(^^;)。明日思い出します。
また、炎上しているブログのコメントで、私の知識の書棚に新しい言葉を追加してくれたあなたに感謝します。

Kenta

>そのためにも学び続けないし、技術を盗み続けたい。

ヤスって奴は、学ばずに盗み続けるわけだw

@IT自分戦略研究所の金武です。
本コラムについて、たくさんのご意見いただき誠にありがとうございます。

本日12時過ぎ、「個人攻撃」「誹謗中傷」にあたると
編集部が判断したコメントを削除いたしました。

▼対象コメント
2010年5月21日 (金) 12:58
2010年5月21日 (金) 13:48
2010年5月21日 (金) 13:57
2010年5月21日 (金) 19:52
2010年5月22日 (土) 23:42

コメント欄は有意義な議論の場として展開していただければと思います。
個人に向けた誹謗中傷、攻撃的な言葉はおやめくださるよう
お願い申し上げます。

また、生島氏に対しても、攻撃的な言葉遣いはお控えくださるよう、
お願いしております。

皆さまのご協力のほど、何卒よろしくお願いいたします。

flatline

誹謗中傷コメントを削除するのはいいのですが、どのような基準で削除するのかを明白にした方がいいのではないでしょうか。
でないと、あたりさわりのないコメントばかりになってしまうような気がします。

@IT自分戦略研究所の金武です。

>誹謗中傷コメントを削除するのはいいのですが、どのような基準で削除するのか
>を明白にした方がいいのではないでしょうか。

編集部による基準は「特定個人に向けた中傷・侮辱発言」です。
具体的には、
「○○という人間はゴミ」「皆あんたのことを嫌っている」
などが相当します。

「そう考えるのは○○の理由で間違っていると思う」
など、意見の相違や議論については対象としません。
賛成意見・反対意見含めて、議論には価値があると考えます。
特定個人に対する中傷は、読者の不利益と判断させていただくことがございます。

推測に基づく人格否定、言葉尻をとらえた執拗な攻撃・侮辱については
「特定個人に向けた中傷・侮辱発言」にあたると判断されますので、
コメントする方は引き続き、攻撃的な表現や言葉遣いはお控えくださるよう
お願い申し上げます。

どうぞよろしくお願いいたします。

flatspot

金武氏へ

> また、生島氏に対しても、攻撃的な言葉遣いはお控えくださるよう、
> お願いしております。

こんなことを言わなければならない、貴方も情けなくないですか?
毎回炎上するブログとそうでないブログがある。この差は何か、あなたは分かりますよね?
もしあなたに@ITの担当者としての責任感があるならば、いい加減、生島氏に直接指導してはどうですか?

あなたは胸をはって、自分の仕事をしていると言えますか?自分の胸に聞いてみてください。我々は、あなた方の行動をちゃんと見てますよ。

AC/DC

>いい加減、生島氏に直接指導してはどうですか?

これ、具体的にどういう行動に出ることを示唆してるのかねえ。
「攻撃的な言葉遣いはお控えくださるようお願いしております。」
って、すでに直接指導してるんだと思うんだけどさ。

それ以上の指導は干渉しすぎでしょ。
っていうか効果ないよ。

浦和サポーターの国籍侮辱ヤジみたいなのがあったらカウントして、定期的にワーストコラムニストとしてランキングしたらどうかね。

むしろ、みながわさんのコラムのように、百害あって一利なしのコラムを排除する仕組みを考えた方がいいかもよ。

Voyager

はじめまして>ALL
技術的には皆様の足元にも及びませんが、ここまでROMして想ったことを。
ユーザー側の視点ですが。

前提条件:
元エンドユーザー社内IT雑用係です(CIO補佐という肩書きをいただいていましたがW 臨死体験をしてから失業中のおぢさんです。)
システム屋さんに騙されないようにするための勉強と
必要なデータ抽出・加工・資料作成等ができる異を目的としたスキルアップの為に@IT等を時々読んでいます。
以下に述べることのは、私の今までの経験:旧職場(小売業)+α(製造業の現場などなど)範囲での事です。
ごく狭いかもしれませんが、過去にPC講師もしていましたので100人ぐらいの中小企業経営の方々と色々話したり、何件かの導入検討の際にお手伝いした経験を元にしています。

で、私が語れるのは効率についてだけかもですが、客としては一番重要視して欲しい項目です。
IT投資の目的って業務効率の向上でしたので。

過去に実際にあった案件で、最初の打ち合わせで出した要求の一部です。

レスポンスは早ければ早いほど。予算内の範囲で最大でお願いいたします。
在庫管理や受発注は特に。使用する者は端末前にいる時間を極力短くしたいのです。
LANのトラフィックは可能な限り少なくしてください。最悪INS64回線で繋がります。(バックアップ緊急回線)

 #以上の条件を、俺は出来るぜ臭を漂わせた営業さんは契約の段階で無視しよとしてました。
 #契約書に64kbpsでレスポンス200ms以内じゃなきゃ半額って入れるのを頑なに拒否されました。
 #3万点の商品から任意の件数の現在庫数量出すのに500msかかるシステムのリプレースだったのに。

余談:
 で、色々なコメント見てると、遭遇したくない方がちらほらと。同じ臭いがします。
 本文に書かれている前提条件(釣針付き要読解力)をハナから無視して絡んでくる
方なんか特に。
 一応、生島氏のコラムは最初からコメントを含めてすべて1度は目を通しています。
 同じような内容の繰り返しを今回が3回目?かな。(笑)
 現在2回目 2009年12月まで読破。コメントは飛ばし読みですが。
 あぁ頭がクラクラする。
 SEGABBSで、良く言われた「過去ログ読んでから書き込め」を実践中(w

ryo

生島さん、お久しぶりです。
本題とは関係ないですが、こちらをちょっと借ります。
#余所で不完全燃焼しましたもので・・・

Voyagerさん、はじめまして、ryoと申します。
面白いお題をありがとうございます。

さて、私ですが、零細ユーザ企業に勤めながら、SE(というかなんでも屋)として開発の仕事も行っている、アラフォーの男です。

>レスポンスは早ければ早いほど。予算内の範囲で最大でお願いいたします。
>在庫管理や受発注は特に。使用する者は端末前にいる時間を極力短くしたいのです。
>LANのトラフィックは可能な限り少なくしてください。最悪INS64回線で繋がります。(バックアップ緊急回線)

INS64回線ならデータ転送がタイトになりますね。

> #以上の条件を、俺は出来るぜ臭を漂わせた営業さんは契約の段階で無視しよとしてました。
> #契約書に64kbpsでレスポンス200ms以内じゃなきゃ半額って入れるのを頑なに拒否されました。
> #3万点の商品から任意の件数の現在庫数量出すのに500msかかるシステムのリプレースだったのに。

であれば、200msでやり取りできるデータは、単純計算で、往復1.6KBになります。
検索時間が100msであれば、やり取りできるデータは、0.8KBになります。

最近のSQLは、ちょっと大きいもので、あっという間に1KBになりますので、行きだけでアウトになりますね。
なので、行きの部分は極力小さくする必要がありますね。おお、ストアドを使うと行きの部分は多少効率化がはかれます。
では、帰り(結果の取得)はどうでしょうか?
やはり0.8KBは小さいですね。例えば後でちょっとデータを足すとなっても、たった100バイトの追加で、単純計算で、約12mかかります。つまり目標に対して12%実行時間が増えることになります。これは無視できないですね。
通常回線の帯域が不明ですが、私としては、バックアップ回線の制約で設計に影響を与えるのはこの場合ちょっと面倒だと思います。

実際にこのお話が出た時期にもよるでしょうが、今現在なら、
・バックアップ回線の速度についてはなるべく現状維持
・通常業務ではスピードアップ
という提案を希望しますし、そういう提案を行いますが、如何でしょうか?
その方が結果としてリーズナブルになると思います。

#ちなみに私は過去に生島さんとやり取りをしましたが、読まれました?

Voyager

まさかレスがあるとは(^^;

ryoさんどうもです。
お名前は覚えていますが、やりとりの内容までは覚えてないです。
#昨年後半のあまりに強烈な方の印象が強すぎて。
#大昔?に某BBSで暴れまくっていた方と同じHN・・・蘇る悪夢?(w

8年以上前の事を記憶の奥底を探って書いたので、条件が一部抜けまま投稿したので、そのような詳しい考察が帰ってくるとは思いませんでした。
これだけで見積もるのは無理かと思いました。
しかも、読み返すと肝心なところが抜けてるし。

結局は200msレスポンスは実現されませんでした(^^;
お騒がせしました。
1回あたりのデータ量はたいした事は無かったですよ。
#確か 送信:約20Byte、返信:240Byteぐらいだったと記憶しています。
#検索文字列は品番のみ(最大10Byte)
#結果は品番・倉庫別在庫数が最大10件だったと記憶しています。

で、何故契約書に200ms以下の条項を入れたかですが、
最初の打ち合わせで
・アイテム数が15,000から30,000まで増えるけど、レスポンス落とさないでね。
・データベースは現システムのOracleをそのまま使ってね。
他にもろもろの条件を提示したところ、
社長の前で相手のSEが
 SE:「倍以上のレスポンスに出来ます」
 社長:「倍以上って具体的に」
 SE:「まぁ悪くて200msぐらいには」
 社長:「それは凄い」
ってなったので既定事実になりました。
横で聞いてて「大丈夫か?」って思いましたけどね。
#どうも元のシステムを作った会社をバカにして、うちなら倍!って失言?したらしいと後日聞きましたが。
結局、元のシステムを作った会社にお願いして、2割ほど体感速度があがったようです。
#測定したけど残してないようです。


いままで20人ほどの業者さんとやりとりしましたが、
3~4人:普通に話せた。
15~6人:専門用語で煙に巻こうとする印象を受けた。
1人:話が明後日の方向に行って、過去案件の自慢話&理想論で独演会(w
    #こんな奴よこした会社は幸いにもすでに倒産したようです
    #当時の手帳を引っ張り出してしまった(w
    #強烈すぎたので色々書いてあったの見て悶絶した(W

Voyagerさん、ryoさん、こんにちは。

#確か 送信:約20Byte、返信:240Byteぐらいだったと記憶しています。
#検索文字列は品番のみ(最大10Byte)
#結果は品番・倉庫別在庫数が最大10件だったと記憶しています。

という条件であれば、つまりC/Sなんですよね。
ストアドプロシージャ前提ですね。

8年前のリプレース案件なら元はVBでしょう。VBでグルグル回しているプログラムが相手なら、最低でも20倍ぐらいは出せるし、さらに64Kbpsであれば100倍ぐらいは軽いけれど、そもそも、64Kbpsが前提になれば、最初からストアドプロシージャを使っているでしょう。64Kbpsで8年前の時点でリプレースするということは、更に10年以上前の中小企業のハードってことで、そのレベルだと、最初から目一杯やってた可能性もなきにしもあらず。

そりゃ、相手を確認しないで無条件に倍にできるっていたらダメですね。
すでにストアドプロシージャ(SQL)でやっているモノを、SQLでやったら速くなるって前提からズレていますから。
当時もグルグルやってるのが多かったから、確認しないで、つい言っちゃったのでしょうが(苦笑)。

10年ぐらい前のハードなら、PentiumII の400MHzぐらいかな。回線が64Kbpsで500msecで遅いと言われたら、今の技術者はほぼ全滅ですな。

そういうギチギチの所でやってきた人達は理論値にかなり近い。
工数も滅茶苦茶少なくできます。

ryoさん、どうもです。メールで残っていますから検索したらすぐに出てきます。

Kenta

@IT編集者

>「○○という人間はゴミ」
生島の「カス」「クズ」を消さない理由を説明してもらおう。
明確にな。

中小企業の受発注画面で表示される在庫数を出す。

アイテム数 30,000点。
ハード PentiumII 400MHz
メモリー 400~600MByte
回線 64Kbps(ギガイーサって1,000,000Kbpsよ)
要求レスポンス 200msec(結果、500msec)

ハードや回線が格段に上がっても500msecどころか、5000msecなんてザラにあるし、工数も滅茶苦茶掛かっている。WEB系のHTMLの転送部分は除くとしても、それでも遅すぎ。

できる人は当時も少なくって、できる人は残念ながら教育担当に廻るのではなく、徹底的な火消し役に廻って、信じられない量の仕事が集中してえらいことになってしまった。

技術の継承ができず、業界として技術者のスキルアップのスピードよりも、ムーアの法則の方が早かったから、もういいや、ハードでなんとかしよう。ってなってO/Rマッパーなんかが生まれたりした。

結果的にできない人が大多数になって、そんな人を見たことがないから「SQLでxx倍、そんなわけない!」ってなるんでしょうけどね。

Voyager

生島さんどうもです。

ほぼ正解です。
当時はストアドって言われてもチンプンカンプンでした。
在庫管理しながらおじちゃん・おばちゃんたちのヘルプデスクしてましたので(W
#導入後にお家騒動?ではじき出されたのであまり触っていないですけど。
#CIO補佐はその後に勤めたほぼ同規模の異業種小売業での肩書きです。
#当時は、総務部リーダーって名刺に書いてあったような。
#2社の記憶がごっちゃになるときがある(W

実は前システムは導入して3年しかたっていなかったので、サーバはPen3 だったとメモには残ってました。
オフコンからのリプレースでやらかした業者がありまして。
経緯は、
12年使ったオフコンのリプレース検討時にやらかした業者の「これからはクラサバ」の言葉に乗って、旧システム導入・・・半年たってもまともに動かず
怒った社長、元システムの会社に声をかける・・・三カ月後本格稼働
2年とちょっと後、限定的プチバブルで店舗拡大、元システム会社に無理してもらったから、システム拡張(ハードはそのまま)を依頼。
相見積りの為に声かけたら。 となります。

その後の勤務先(CIO補佐w)で5年前のリプレース時に声をかけたのですが、
採用には至らず、その後お付き合いは途絶えてしまいました。残念です。
渋チンの会社だったので、大変だったです。
採用されたのは、COBOLバリバリでオフコンからのお付き合いの業者。
Oracle+Access2000+リモートアクセスで端末30台。(W
ストアドがいいって言ったら、「お前いくらもらった!」って(W
どう考えてもパフォーマンスが・・・高くてもパフォーマンスが2桁以上・・・

#その後、アプリをコピーせずにちゃんとライセンス買ってって申請を出しつづけ
#このクソ遅いシステムをどうにかしろといわれ続け・・・
#ストレスたまって心臓止まりました(W
#ネットショップでWEB構築に使っているAdobe製品がすべて割れ物ってどうよ
#遅いのはあんたのせいでしょうが。

ryo

Voyagerさん

ご返信ありがとうございます。

ryoというHNは、1年程前から使っているだけですので、大暴れした人とは多分違うと思います。ここ数年ですが、プログラミングだけでなく、ユーザさんへの説得とかやってますとある種の緊張感を持って話をしなければならないのですが、そのせいか、ふっとしたときに理屈をこねたくなることがあり、こういう所で練習がてら理屈をこねています。

私にとってですが、実際にあった話ってそれだけで説得力を感じるので情報が欠落していても話が大きくずれることは無いかと思います。事実、Voyagerさんの返信には違和感を感じません。

#このように書くと一部の人から反感を買うかもしれませんが、まぁ一個人の感想と受け取って下さいね。

で、件のSEさんですが、
>#どうも元のシステムを作った会社をバカにして、うちなら倍!って失言?したらしいと後日聞きましたが。

まぁ、そのSEさんの気持ちを代弁すると、倍というのは意気込みをいったところでしょうか?
会話の行間を補足させて頂きますと、

 SE:「倍以上のレスポンスに出来ます」
   (少なくともSQLの実行部分は、倍になるようチューニングしてみます)。
 社長:「倍以上って具体的に」
 SE: (うわぁ、具体的ってどうしよう。。。500msecとか言っていたな・・・倍以上なので、)
「まぁ悪くて200msぐらいには」
 社長:「それは凄い」

というわけで、倍以上というのと200msの間には何のつながりもありませんでした。という落ちでしょうか? 何れにしても良く聞く話です。

>いままで20人ほどの業者さんとやりとりしましたが、
>3~4人:普通に話せた。
>15~6人:専門用語で煙に巻こうとする印象を受けた。
>1人:話が明後日の方向に行って、過去案件の自慢話&理想論で独演会(w

このての話ですが、私の経験(この場合開発者としての経験の方が強いですね)を言わせて頂きますと、

20%:出来る人
80%:出来ない人

ですかね。恐らくですが、出来ない人って言い訳する為に煙に巻こうとするのでしょう。私自体が煙にまかれることはあまりないのですが、正直に告白しますと煙に巻いたことはあります。
# えぇー何度もありますよ、

過去にあった話で面白いのが、あるプロジェクトでユーザ企業側のアドバイザーで打ち合わせに参加したことがありますが、ベンダーさんが私に敵意むき出しで接して来てまぁ私もそこは人間なので何度も怒ることしばしばなのですが、私が居ないとそのベンダーが専門用語を使って煙に巻くので座っているだけで良いからとか言われて、最後の方は実際に座っているだけでしたが、
『こんなんでお金をもらってよいの?』
とか思ったことがありました。

ryo

生島さん

ご返信ありがとうございます。
まぁ、お互いに過激な発言が大好きなので、こういう制限下で会話するのは私にとってもしんどいのですが、せっかく返信頂けたのでコメントします。

「SQLでX倍」
の話ですが、余所でも言ったのですが、一般論として他の言語からSQLに置き換えたからと言って速度がX倍(実行時間が1/X)になるという話は聞いたことがありません。
で、個別の話をしますと、昔になりますが、JavaのCMP Entity Bean(まぁORマッパーですかね)で、ロクに最適化しないで実行時間がX倍になったということはありました。ただ、これは作りが悪かったですね。
その他、Ruby On Railsを使うと感覚的に実行時間が数十倍あるという認識はあります。

で、他の方も言われていましたとおり、一般論としてSQLに置き換えるとパフォーマンスが上がるのならやはりその根拠を示して頂かないと私も納得しません。

こういう風に言いますと、『一般論としてSQLに置き換えてもパフォーマンスが上がらない根拠を示せ』と言われそうなのですが、以下、私の考えを書きます。

SQLにせよ他の言語にせよ最終的には機械語で実行されます。
つまり、
 ソースコード → 翻訳 → 実行(機械語)
となるでしょう。この観点から言いますと、C言語もSQLも同様に実行されます。
ちょっと暴論かな?
では、SQLの場合ですが、
 ソースコード → 翻訳 → 実行(仮想マシンコード)
となるでしょうか? まぁ想像ですが、大きくは外していないでしょう。仮想マシンというと要するにJavaやC#と同様になりますが、まぁ私にとっては
SQLの実行パフォーマンスは、その位の言語(JavaやC#)と同程度という認識です。
こういうと、
『SQLはオプティマイザーがあるので有効に使えばX倍になるでしょう』
となるかもしれませんが、それはもう個別のDBMSの話になりますし、オプティマイザーを有効に使うという点で既に『単にSQLでX倍』って話になりませんよね?
また、今現在のところ自動でSQLをチューニングしてくれるDBMSを私は知りません。

で、Voyagerさんの例を出しますと、
元が500msでそれを倍以上の200msにすると言う話でしたが、それは無理だったいうことです(正確には試していないとのことですが)。で、生島さんは、

>ハードや回線が格段に上がっても500msecどころか、5000msecなんてザラにあるし、工数も滅茶苦茶掛かっている。WEB系のHTMLの転送部分は除くとしても、それでも遅すぎ。

とハードルを下げる方向に話を持って行っていますが、5000msecでしかプログラムを書けないエンジニアは、Javaで書こうがSQLで書こうがどんな言語を使っても5000msec以上のシステムは作れないと思いますが如何でしょうか?

先ほど私は、Voyagerさんへの返信で、

20%:出来る人
80%:出来ない人

と書きました。この業界ですが、確かに出来ない人が多いです。その中にはSQLすら出来ない人もいるでしょう。ただ、申し訳ないのですが、私の周りですが、80%の中の人たちもSQLが出来る人は多く、そういう人が書いたSQLも5000msecなんてざらにあります。如何でしょうか?

後、余計なお世話かと思いますが、
『SQL ServerとOracleの一番大きな違い』
のようなコラムを書くと好評のようなので、あまり炎上を狙ったコラムは控えた方がよろしいかと思いますよ。

AC/DC

>で、他の方も言われていましたとおり、一般論としてSQLに置き換えると
>パフォーマンスが上がるのならやはりその根拠を示して頂かないと私も納得しません。

もうちょっと待ってあげようよ。
それらしい数値をどうでっちあげようか、必死になっているところだと思うからさ。

CMP

久々に「大人」同士の会話を聞いているような感じがしたw

ryoさん、おはようございます。

炎上を狙っているのではありません。対立する意見が多いことを承知で、衝突を恐れずに書いているだけです。

SQLでやるというのは複雑なSQLを使うという意味で書いています。
RDBMSを使う以上、他の言語でというのは、単純なSQLで処理することを指しています。

次のエントリーに書きましたが、

 ■ SQLで処理
    (複雑なSQL)→ オプティマイザ(アルゴリズム生成)
       → 実行

 ■ 他の言語で処理
    アルゴリズムコーディング → (単純なSQL)
      → オプティマイザ(アルゴリズム生成) → 実行

複雑なSQLであっても、単純なSQLであっても、理論値の話をするならば、SQLのチューニングを行うのは当たり前の話です。複雑なSQLでは、自動生成されたアルゴリズムが一致するまでSQLをチューニングするので、他の言語で書かれたものと最低限一致します。
コーディング量はアルゴリズムが要らない分減りますし、余計な処理が減る分、(ネットワークを挟んでループなんてあり得ない)パフォーマンスも上がります。RDBMSを使ってSQLを使わないのは、タイヤの再開発になりますから、工数が掛かるし、同じ筐体にあってもプロセス間通信という無駄な処理が繰り返されますからパフォーマンスが落ちるのです。

最低限と書きましたが、例えば、SQLは結合のやり方が何種類もあって、データの分散を見てオプティマイザが自動で結合のやり方を変えます。

他の言語で書いたときは、ネスティッドループか、ソートマージジョインぐらいしか再現できませんが、SQLではハッシュキーを生成して結合に使うと速くなるなら、ハッシュジョインもできます。
(ハッシュジョインの方が速くなるので、最近はソートマージジョインが選択されることはほぼないと思いますけどね)

他の言語でハッシュジョインのコーディングを行うと大変ですが、

TABLE_A a
INNER JOIN TABLE_B b
    a.KEY = b.KEY

たったこれだけで、ハッシュキーを作って結合するか、インデックスを使って結合するか、a.KEY、b.KEYでソートしてから結合を行うか、その他の方法で結合を行うか、データの分散具合、ヒット率の予想から、DBエンジンは適切な方法で結合し実行します。

他の言語でデータの分散が変わったときのために、何種類もアルゴリズム書いて、条件によって、使うアルゴリズムを変えるなんて事実上できないでしょう。

つまり、理論上は、RDBMSを使ってSQLより速く処理する方法はあり得ない。コーディング量もひっくり返ることはあり得ない訳です。

理論値でって、言ってきているのは、下手糞にやったらいくらでも遅く、工数を掛けてコーディングすることは可能ですから、できない人の理屈を持ち出しては議論にならない。

チューニングの手間が抜けているって思うかも知れませんが、頭の中では、先にアルゴリズムを作って、そのアルゴリズム通り処理させるSQLを考える。
それが会話のスピードでできるようになります。から、ほぼ最後に確認するだけですよ。

この辺も読んでみてください。
http://el.jibun.atmarkit.co.jp/g1sys/2009/12/post-59d3.html

子牛

生島さん?

はじめから具体的にこう書けば、炎上もしないし、誰も文句言わないと思うのに。

2010年5月26日 (水) 06:19に書かれたコメントの状況下であれば、そりゃOO言語こねくりまわしてなんとかするより、SQLで処理したほうが効率的なことは誰もが認めるはず。

そもそも一般論としてSQLとOO言語を比較するというのがおかしい。生島さんの主張を裏返してみると「RDBMSを使わないシステムでもOO言語は使われますが、RDBMSを使わないシステムではSQLなんて使わないから、OO言語に比べてSQLなんてダメ」ということになります。これだって変でしょう?

最初のフォーマットに戻って整理してみます。

1.業務系では効率がトレードオフできない必要条件

これはごもっとも。ただしRDBMSのアクセス効率だけが最優先ではない。
「RDBMSのアクセス効率 = 業務効率」ではなく、必要条件は「業務効率」の向上であって「RDBMSのアクセス効率」ではないことに注意されたい。貴殿の主張は「RDBMSのアクセス効率」に限って言えば全面的に正しい。でも「業務効率」の向上はそれだけでは言えないことにご注意を。

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

ここで一般論とか言っちゃうから議論がおかしくなっている。
先の条件下では正しい。しかしシステムはそれだけじゃないからね。
全体最適化を考慮して議論すべきです。

3.SQLとオブジェクト指向言語は分業すべき

そりゃそうでしょう。分業すべき。あたりまえです。
そのあとで何で「全員がSQLをやるべき」ってなっちゃうの?
SQLやるヒトとOO言語でUIや業務ロジック作るヒト、それぞれ必要でしょ?
SQLでUIは作れませんよ(でもだからといって私は「OO言語のほうがSQLより優れている」などという暴言をはくつもりはありませんが)

以上、私なりに「なんでこんなに噛み合ないかな」と感じた理由を整理してみました。老婆心ながら。

ryo

生島さん

ご返信ありがとうございます。

子牛さんが興味深いコメントをされいますね。子牛さんのコメントに生島さんがどう返信されるか興味がありますので、よろしければそちらを優先させていただければと思います。
私のコメントはその後にでもさせていただきます。

oumi

みなさんのおっしゃることはもっともなことも多いのですが、考えてみると
「過去の記事を要約して、前提条件としてきれいにまとめたものを、まず記事の先頭に張るべきだ。」
ということになりかねないと思うのだが・・・
酷ではなかろうか・・・
彼の言わんとする内容の元、根拠、モデルなども過去には書かれていると思うのだけどなぁ・・

書く人の配慮、読む人の配慮、さてどっちなんでしょう・・・

ryo

oumiさん

はじめまして、ryoと申します。

失礼ながらコメントさせていただきますが、子牛さんの質問ってそういうことではないと思いますのですが・・・

配慮の話であれば、例えばですが、
『SQLはオブジェクト指向言語の数十倍の効率』
と書かずに
『多くの業務アプリ開発では、SQLは、ORMを使ったオブジェクト指向言語の数十倍の効率』
と書けば、少ない手間で多くの無駄な議論を省けるかと思います。

生島さんの言いたいことって
『現在のところ、多くの業務アプリ開発では、SQLは、ORMを使ったオブジェクト指向言語の数十倍の効率』
ということでよろしいですか?

子牛さん、おはようございます。

そんなことは、全部、過去のも含めて何回も何回も書いているって。
毎回同じことは書けないって、これも何度も何度も書いています。
もう、一年半も同じことを何度も書いているけれど、テーマが大きいから一回では書ききれないのです。


OO言語って言ったって数は何種類もあるんだから、自分の得意なモノで同じロジックを書いて比べたらいい。これも何度も書いているでしょう。

ちなみに、これをJavaでわたしが書いたら約5倍で400%でした。
http://www.g1sys.co.jp/seminar090515.html

SQLは資料は移送項目ぐらいしか書きようがないけれど、Javaの方は相当な資料を書かねばなりません。それはどのレベルの資料を書くかはプロジェクト次第ですから差があります。大手で要求される資料レベルで考えれば2000%では足りない。

現実のプロジェクトではもっと複雑なシステムはいくらでもあるので、複雑になればなるほど、巨大になればなるほど差が広がります。

唯一絶対的に言えることは、理論値として工数とパフォーマンスの両方とも、絶対にひっくり返らない。

全体最適化というのは、理論値として工数とパフォーマンスにおいてトレードオフが成りたつときに必要なモノで、トレードオフがないときには必要ない。

現実には、どうしてもできない人(開発・保守とも)に合わせて最適化するだけです。それは、理論を曲げて、できない人に合わしているだけですね。

もっと最初に戻って、みながわさんに対して、お互いの人格攻撃なんてわたしは眼中にない。だから、「炎上したコラムについて」その技術的なお互いのやりとりに対して、効果に差がないのに、社内SEとしての最適化の結果にガタガタいうな。そんなことを気にするなら効果がでるSQLをもっと気にしろよ。って書いただけなんです。

みながわさんは、OO言語はしっくり来ない ≒ できないのです。

その「できない」は「あり得ない」と批判した人が少なからずいるけれど、なぜ、理論値として効果の高いSQLは、「できない」が認められるのか?

その批判は技術者として、ダブルスタンダードでおかしいと言ってるのです。

皆さん、すみません。

> ちなみに、これをJavaでわたしが書いたら約5倍で400%でした。
> http://www.g1sys.co.jp/seminar090515.html

適当に細切れにして、一般的によく求められるコーディングで約5倍でした。
O/Rマッパーで自動生成したようなヤツでは試してない。
そこまでレベルを落とすと、コーディング量だけで10倍とか行くかもしれないし、どんな資料を書くのか想像も付かない。
ごめんなさい、そんなプロジェクトは逃げることにしているので、経験は直したことしかないです。

パフォーマンスはレコード数によるから何とも言い難いけど、100倍とか1000倍とか……。

そんな下を見て議論しても意味がないので、試したい人は、どうぞご自身でお願いします。

Kenta

ありえないのはお前。

>みながわさんは、OO言語はしっくり来ない ≒ できないのです。

>その「できない」は「あり得ない」と批判した人が少なからずいるけれど、>なぜ、理論値として効果の高いSQLは、「できない」が認められるのか?

「できない」は「あり得ない」なんて批判はほとんどの人がしていない。
批判者の9割以上は、
「できない」のに否定するのは「あり得ない」と批判している。

お前がO/Rマッパーを「できない」のに否定しているのと同じ。

Kenta

@IT編集者

>「○○という人間はゴミ」
生島の「カス」「クズ」という言葉があるコメントを消さない理由を説明してもらおう。
明確にな。

@IT自分戦略研究所 編集部

@IT自分戦略研究所 編集部の岑です。
いつもエンジニアライフをご覧になっていただき、
また、コメントご投稿につきましてご配慮いただき、ありがとうございます。

生島様におかれましては、問題となる言動につきましてお控えいただくようお願いし、
その後ご配慮いただいておりますので、過去にさかのぼっての削除は今のところしておりません。
今後、もし同様の書き込みが続いた場合は、問題と判断した場合は削除とさせていただきます。

削除など、運営に関するご意見やご質問につきましては、下記お問い合わせまでご連絡いただけますと幸いです。
http://el.jibun.atmarkit.co.jp/info/contactus.html

エンジニアライフの運営につきましては、今後とも最善の形を模索したいと思いますので、
ご意見ご質問などは、お問い合わせからご連絡いただければと思います。

何卒よろしくお願いします。

CMP

「やればできるけどやらないし、それ以上に効率のいい方法でできるから必要ない」で否定するのと、「やったけどよくわからなかったが、別の方法でもできたから必要ない」で否定するのとでは、違うと思うが。

O/Rマッパーを作った人はすごいが、O/Rマッパーを使ってる人はすごくないと思うのは間違った考え方なのかな?どう考えても、作った人以上に使いこなせている人はいないと思うが。

Kenta

@IT編集者

>生島様におかれましては、問題となる言動につきましてお控えいただくようお願いし、
>その後ご配慮いただいておりますので、過去にさかのぼっての削除は今のところしておりません。
>今後、もし同様の書き込みが続いた場合は、問題と判断した場合は削除とさせていただきます。

おかしいだろ。
なんで他の人間の書き込みは控えるようにお願いすることなくいきなり削除なのに、生島だけはそんなに猶予期間があるんだ?
しかも、
>今後、もし同様の書き込みが続いた場合は、問題と判断した場合は削除とさせていただきます。
今後生島が「カス」とか「クズ」とか言ったとしても、問題でないと判断する場合もあるわけだ。
他の人間は他人を「カス」とか「クズ」とか言えば削除されるのに、生島は言ってもいい場合があるわけだな。
どれだけ特別扱いしてるんだ?
だから生島が大喜びして調子乗ってるんだろうが。
子供に飴だけあげてどうする。ちゃんと教育しろ。

Kenta

>「やればできるけどやらないし、それ以上に効率のいい方法でできるから必要ない」で否定するのと、「やったけどよくわからなかったが、別の方法でもできたから必要ない」で否定するのとでは、違うと思うが。

アホか?
生島はO/Rマッパーを理解するだけの能力がないだけの話だ。
こいつの主張は全部そうだろ。
自分が出来ないことをむきになって否定しているだけだ。
O/Rマッパーも理解できないし使えない。
資格もなにひとつ取る知識はない。
こいつが批判しているのは、自分が出来ないことを批判してるだけ。
こいつが言いたいのは、
「みんな、俺が出来ないことはやらずに、俺が得意なことで仕事しろよ。そうじゃないと俺は技術者と認めないぞ。ぷんぷん」
って幼稚園児のわがままだけだ。

ryo

生島さん、みなさん

大変残念ですが、雑音が大きいので私はこの辺で失礼します。
#私も過激な発言が大好きなので、これ以上煽られるとついつい乗ってしまいそうになるので・・・

この後の展開が知りたい人は以下のコラムを参照してください。

2009/06/16 19:10:00 上流の技術者はSQLを高いレベルで習得すべき

ここで私は生島さんと議論しました。1年前ですが、恐らく今後の展開はこの時とあまり変わらないかと思います。
またこの議論の後にあった

2009/06/26 18:30:00 【継承】など何が便利か分からない

のコラムですが、ここで生島さんのホンネが見えます。

あまりにも中途半端なので1点だけ、コメントしますと、
恐らく生島さんの 『SQLでX倍』の話は、『N+1問題』について話ているのかと推測しています。
#ググればNiceなコラムが引っかかります。

それでは、またどこかで。

ONEOUTS

がっかりです。
結局、理論値についての根拠の提示は無視ですか。
「○百倍のパフォーマンス!」って、二束三文の欠陥品を誇大広告で売りつけようとする怪しい商人みたいですね。
ああそういえばこのコラムは「商売」で書いているんでしたか。
人間的には問題があっても技術力には裏づけがある人だと思っていたのに失望です。

>唯一絶対的に言えることは、理論値として工数とパフォーマンスの両方とも、絶対にひっくり返らない。

つまり生島さんのいう理論値というのは、生島さんの経験したごくごく狭いフィールドでの経験値にすぎないということですね。
期待した分だけ失望感も大きいです。
みながわさんのように、最初から何もわかっていないことが明らかなコラムよりもたちが悪いです。

これからも根拠のないハッタリをかまして炎上マーケティングを続けてください。
ほくそえみながら拝見させてもらいましょう。

CMP

Kentaさんへ

私の生島氏の解釈とは、ちと違うかな。
>「みんな、俺が出来ないことはやらずに、俺が得意なことで仕事しろよ。そうじゃないと俺は技術者と認めないぞ。ぷんぷん」

RDBを使用するシステムというごくごく狭い世界の技術者向けという前提で、
「へたれな俺ですらSQLできるのに、技術者を名乗ってるお前らがSQLできないってのはおかしいだろ?だから、SQLできない奴らは技術者として認めねぇ」
なんだけど。
まぁ、へたれは言いすぎかな。

子牛

今日はずっと外回りで、帰ってきてここを覗いてみると、うーん...

ryo さんの「2010年5月26日 (水) 16:48」に投稿されたコメントを参考に、引用されていた議論を斜め読みしてみたら、話が噛み合ない理由がさらに明確になりました。生島さんと、私では使っている言語が違うからなんですね。いやどちらも日本語なんですけど、すみません。生島さんの表現、分からないところが多く、真意を汲み取れません。それに私の質問にも答えて下さってないということは、おそらく私の意図が伝わってないのでしょう。これじゃあ議論になんてなりませんな。

oumiさんが、

> 書く人の配慮、読む人の配慮、さてどっちなんでしょう・・・

と書かれてる件について、これは書く人が配慮すべきという点は明白です。

だって、書き手と読み手のうち、積極的にコミュニケーションしたい人はどちらでしょう? 不特定多数の読者に頼まれて書かれているコラムですか? ここってそういう場でしたっけ?

「何度も何度も書いているじゃないか」と逆切れする前に、やることあるんじゃないですか? と文句のひとつも言いたくなります。心ある著者というか常識をわきまえている書き手(もしくは教養のある人、という言い方が厳しければ、他者の書かれた記事をきちんと読んで記事とはどうあるべきかを学んでいるヒト)であれば、通常は「引用」とか「参考文献」という手段を提供します。とくにWeb記事だったらハイパーリンクすればいいだけだし。

あとせっかくなので生島さんの疑問に1つ答えておきましょう。

> その「できない」は「あり得ない」と批判した人が少なからずいるけれど、なぜ、理論値として効果の高いSQLは、「できない」が認められるのか?

生島さんの主張される文脈において、理論値として効果の高いSQLを「できない」が認められるのはおかしい、それは仰る通りです。しかし先のコメントの繰り返し、またryoさんの指摘されていることとも繰り返しになりますが、生島語では、「私の主張したい状況では」という説明が無条件で省かれている点が問題なんです。

ここで「技術者は...」とかやっちゃうからおかしくなる。一般論としての技術者はSQLができなくてもオブジェクト指向は身につけておいてほしい。なぜならばSQL以前に、データベースを使わないITのシステムはたくさんあるからです。そしてこの@ITという場所はIT技術者を対象とした場でありデータベース技術者に特化した場所ではないので、「技術者は...」と言い出すと、アレレ? ってなっちゃう。

ということも生島さんに分かってもらえるかどうか分かりませんが、まあ、ryoさんほか、きちんと話ができる方もいるんだなあということが唯一の収穫でした。

残念ですが、これ以上は実りがないようなので、消えることにします。さようなら。

No SQL

@IT担当者殿へ

> 生島勘富 2010年5月26日 (水) 16:40
>
> 憂鬱な人なのかな~。

また問題発言をしていますが?
表面上おとなしくなったようですが、性根(商魂?)は変わっていないようですね。

きむらよしひさ

多くの業務APはRDBMSを利用しているのだからSQLが重要だということに間違いはないと思うし、実行計画が読めないとちょっとヤバイ。

業務APを開発するのにオブジェクト指向が絶対必要かと問われれば、「なくてもなんとかなる」と答える。もちろんオブジェクト指向で業務をモデル化し、実装に落とし込んでいく方法論に対して異論を挟むつもりはないが、トラディショナルな手法であるDFDからER図を起こしていく手法(DOA)もまだまだ現役である。

だから生島氏の言うことはもっともなことだと思う。ただ、オブジェクト指向の勢力も拡大しているということは知っておく必要があるし、ちゃんと勉強はしておくべきだろう。RedmineのようなOSSがオブジェクト指向言語で開発されているのだから教材には事欠かない。ちなみにオブジェクト指向言語を学ぶ上でJavaは余りお薦めできない。その理由は本質的じゃないところでハマり易いと思うからだ。その点Rubyは学習にも適していると思う。

で話は変わって、業務APを効率良く開発するために最近はSAPIENS,
Magic uniPaaSやGeneXusのような開発ツールを使うのが(万能ではないにしても)良いということがわかってきた。もちろん、これらの開発ツール(プラットホーム)にはRDBMSが使われているからSQLは分かっていなくちゃいけないし、オブジェクト指向的な考え方も取り入れているからオブジェクト指向も理解しておく必要がある。どっちがどうじゃなくて両方必要だよってことを私は言いたい。

AC/DC

>理論値でって、言ってきているのは、下手糞にやったらいくらでも遅く、工数を掛けてコーディングすることは可能ですから、できない人の理屈を持ち出しては議論にならない。
>唯一絶対的に言えることは、理論値として工数とパフォーマンスの両方とも、絶対にひっくり返らない。

あいかわらず「理論値」を連発してるけど、根拠を提示する気はないのね?
提示することができない、というのが正解なんだろうけどさ。
議論にならないって、そりゃこっちが言いたい。
何の根拠も示さず「これが正しいのだ!絶対なのだ!疑うやつはカスだ」と言われたら、そりゃ議論にも何もなりゃしませんがな。

過激な言動だけは控えるようになったね。

No SQL

きむらよしひさ 2010年5月27日 (木) 01:24

オブジェクト指向の要否とか、ましてやオブジェクト指向「言語」どう学ぶかなんて論じている時点で、今時の技術者として決定的に遅れを取っている。
申し訳ないけど、そんなものは10年前の議論で、オブジェクト指向も万能ではないことを理解したうえで、既に使っているところは使っているし、使わないとは使わない。あえてオブジェクト指向の成長分野を言えば、組み込み系か?(組み込みは門外漢なんで、よう分からんが)

理論値で絶対にひっくり返らない。っていってる。
理論値の絶対値を言ってるわけはじゃないでしょうが。

そもそも、効率って書いてるのよ。
効率は工数とパフォーマンスをあわせたモノだって。
数倍~数十倍の差は付きますよ。

わからんかな?
別にOO言語をやったらアカンとか一言も書いてない。必要もないとは一言も書いてない。
OO言語に比べてSQLの方が効果が大きい。OO言語の解説する前にSQLをやるべき。
単純にそれだけのことしか書いてない。

絶対値なんかに意味はないの。
全部に個別の事情が入るからそんなモノで議論にならないっていってるでしょうが。
反論は、OO言語で理論値(ものすごくできる人でもいい)SQLで理論値(ものすごくできる人でもいい)がシステム全体で逆転するって言えば良い。

ryo

やっぱり煽られました・・・・

1点だけコメントします。

>全部に個別の事情が入るからそんなモノで議論にならないっていってるでしょうが。
>反論は、OO言語で理論値(ものすごくできる人でもいい)SQLで理論値(ものすごくできる人でもいい)がシス>テム全体で逆転するって言えば良い。

私は、過去にSQLが遅いのでSQLを崩して、C言語でJOINをやらせて高速化しました。OO言語ではないですが、今だったらC++を使うでしょう(なぜってハッシュクラスがあるから)。
私の認識(どうもそういうオレ理論が通用するので書かせて頂きますと)ですが、
言語による実行速度順は以下のように考えています。

1. C/C++等の仮想マシンを使わないコンパイラ言語
2. SQL Java C#
3. スクリプト言語
4. ORM

これはあくまでもオレ理論ですので、生島さんとの会話だけで使います。(そもそもこういう比較があまり意味がないと思ってます)。

本当に出来る人にとっては、DBMSのオプティマイザの動作以上のものを作ることは現在のところ可能でしょう。
また、現在のプログラミング言語にはそれを補助する道具(ライブラリ)も揃っています。
生島さんの今までの理屈を整理すると

1.DBMSとの通信
2.オプティマイザ以上の効率的なコードがが人間に書けるか

になります。もう細かく突っ込まないですが、1にせよ、2にせよ一般論(または理論値)では語れないでしょう。ケースバイケースになります。

もう一度繰り返しますが、きちんと出来る人が書いたら、少なくとも現在のところ、DBMSのオプティマイザを超えたパフォーマンスを出すことは不可能ではありません(ケースバイケースですね)。
また、SQLの実行効率を否定する製品もあるのを知らないのですか?

何か?ってお・し・え・て・あ・げ・な・い
#あぁ~やっぱり煽ってしまった・・・

Kenta

>憂鬱な人なのかな~。

自分を過大評価しているな。
お前が俺に憂鬱なんて感情を抱いてもらえると思っているのか?
憂鬱なんて感情は、現状を変える力も気概もない人間が持つ感情だ。
お前が俺に感じさせることが出来るのは哀れみと怒りだけだ。
憂鬱を感じてほしいなら、俺以上の地位、収入、技術者としての立場を得てから望むことだな。
今俺の成長が止まって、お前が人の二倍努力したとしても後10年はかかるが。

宮崎牛

多分そのSQLが下手に書かれていただけのことではないでしょうか?

Kenta

>理論値で絶対にひっくり返らない。っていってる。
>理論値の絶対値を言ってるわけはじゃないでしょうが。

言葉の意味、わかって使ってるか?

根拠のない理論値は存在しない。
お前の経験則だけから導き出された解を理論値とは呼ばんのだよ。
それは経験からの推測値に過ぎない。
理論値の絶対値って言葉もちゃんとどういう意味になるかわかって使ってるか?
知ってる言葉を組み合わせて使ってるようにしか見えないが。
そうでないなら用法を完全に間違えている。国語の勉強をしなおせ。

憂鬱に反応された方に。
すみません。特定の人に向けた暗号だったのですけれど、特定の人はいなかったみたいです。こちらとしては連絡を取ろうとしても、ダミーのメールアドレスでは連絡とりようがないので。失礼しました。

一部、「商売しようとしている」みたいなことを書いてらっしゃる人がいるように思います。「商売をしようとして」ではなく、「商売として」書いています。

思っているだけですが、「商売しようとしている」のが気に入らないという意図でコメントされている方は、意思表明していただければ。

よろしくお願いいたします。

ryo

ここで商売をされるのは問題ないと思います。
逆にお尋ねしますが、

本当に商売になってます?

大変失礼ですが、こんなに不毛に荒れて、ここ1年で識者は離れて、(これも失礼な言い方ですが)程度の低い人しか残っていないような印象を受けるのですが・・・

ただ、実際に有効な営業ツールになっているのであれば、私もやってみようかとは思ってます。

#完全に横道にそれますが、ご返信を希望します。

ryoさん、こんにちは。

サイレントマジョリティは関係ないんじゃないですかね。

派手に書けば何%かは程度の低い人が来てしまいますし、
離れていく人もあるでしょう。気にしてないです。

コメントしている人は訪問者の1%にも満たないので、
税金みたいなモノです。
邪魔ですが仕方がないです。


それは現実社会でも、何%かはどうしようもないのが
いるから仕方がない。今までは、大体、ほぼ全員に
多少、脱線しても返せてたのですが、レベルの低い人
のためにそれがままならなくなったことは、非常に
残念です。

ryo

生島さん

関係ない話でご返信ありがとうございます。

社会勉強のつもりで、私も応募しています。

@IT自分戦略研究所 編集部

お世話になっております。@IT自分戦略研究所の岑です。

運営に関するご意見をお送りいただいた皆さま、ありがとうございます。
「公平性に欠けるのではないか」とのご指摘をいただき、
本コラム中のコメントについて、過去にさかのぼって
明かな問題発言を削除させていただきました。

削除対象は下記となります。
2010年5月20日 (木) 21:45
2010年5月20日 (木) 23:10
2010年5月26日 (水) 16:48

よろしくお願いいたします。

みながわけんじ

生島さん こんにちは

私も社内SEですから、社員はお客さんとして見ているわけで、お客さんの都合に合わせて、自分のスキル内で商売をしています。まあ商売といっても首にならないように給料をもらっているわけです。

public static では、WEBアプリの場合スレッドセーフでなくなるという指摘が何名かの読者ありましたが、WEBアプリの場合、ページ間の遷移で値を引き渡す方法は、session変数かQueryStrigなどの方法であるために public static 変数なんて結局あまりつかわないんですね。それで障害が起こらず実際に安定稼動しているのです。

生島さんもご自身の信じる方法で商売をしてください。たぶんこのコラムは信じるための確証をえるための一部の有識者への誘いが目的だと思っています。

若いと思ってもあっというまに人生なんて10年、15年経ってしまいます。出口のない迷路にはまったら、とりかえしのつかないことになります。情報収集し迷路から光の見える出口にたどりつく判断力が大事だと思います。

Kenta

>レベルの低い人

レベルが低いのはお前だろ。
自分のレベルを高くしてから偉そうなことは言ったらどうだ?

Kenta

>コメントしている人は訪問者の1%にも満たないので

このコラムを見て、お前と仕事したいと思う変わった奴の割合が
およそ1%だろうな。

Kenta

>特定の人に向けた暗号だったのですけれど、特定の人はいなかったみたいです

暗号ってw
誰か連絡を取りたい相手がいるなら直接コメントででも、名指しで連絡を取りたいと頼めばいいだけだろ?
何が暗号だよ。
そんなことやっといて、効率が大事?笑わせてくれるじゃないか。

flatline

みながわさん、こんなところで、他人のコラムにコメント書いている場合ではないと思うのですが。
ご自分のコラムの方を何とかするべきでは?

みながわさん、こんにちは。

チャチャを入れてすみませんでした。
ここまで非道くなるとは思ってませんでした。

岑さん、どうも。

私側だけ残っていたら、私がアホに見えるので気遣ってくれたんですね。
私の発言には、そんなに気を遣って貰わなくても良かったのに。

まあ、ご要望だから仕方ないね(苦笑)

Kenta

アホだこいつ。

>私側だけ残っていたら、私がアホに見えるので気遣ってくれたんですね。
どこまで自分に甘い奴なんだ。

>運営に関するご意見をお送りいただいた皆さま、ありがとうございます。
「公平性に欠けるのではないか」とのご指摘をいただき、
本コラム中のコメントについて、過去にさかのぼって
明かな問題発言を削除させていただきました。
お前の問題発言を削除されたんだよ。
気遣いじゃない。

Kenta

@IT編集者

>運営に関するご意見をお送りいただいた皆さま、ありがとうございます。
「公平性に欠けるのではないか」とのご指摘をいただき、
本コラム中のコメントについて、過去にさかのぼって
明かな問題発言を削除させていただきました。
つまり、問題発言とわかっていながら、生島の分は「気遣って」残していたわけだ。
特別扱いをしていたことを認めてしまったな。
他のコラムニストにどう説明するつもりだ?

ONEOUTS

>レベルの低い人

類は友を呼ぶ、ということですね。
ああ、みながわさんも来てるではないですか。

私はIT技術者の転職サポート業ですが、たまに来ますよ、あなたがたのような方が。
スキルや学歴をえんえんと自慢して、社会人としての最低限の礼儀やコミュニケーション能力すら持っていない人が。
「おれはこんなにすごいスキルを持っていて、こんなに大きな仕事をやってきて、こんな有名会社の部長や課長とのコネクションもある。なのに転職が成功しないのは、お前の能力が低いからだ」とのたまう人が。
あなたがたの会社が倒産しないことを祈ります。
私にはあなたがたを紹介する自信がありませんので。

nanashi

初めて書きこみます。
いくつか記事(とコメント)を読みましたが、内容以前に記事として最低限のレベルに達していません。しかもかなり不快なレベルで。思いついた問題点をあげてみます。

1.前提条件を明記していない
記事の最初に前提条件を明記するのは当然のことです。毎回必ず明記します。
毎回明記できないほど大量にあるならば、前提条件を記した記事へのリンクを置き前提条件はリンク先に準ずる旨を明記します。(前提条件が多すぎる事自体も問題ですが)
続○○や○○Part2のような連載記事である場合は、省略しても構わないかもしれませんが、その場合はPart1へのリンクを置いた方が親切でしょう。

2.言葉を一義的に定義していない
「SQL」という言葉は文脈によって、「ストアドプロシージャ」・「複雑なSQL」・「(Java等の)他の言語の中に書かれたSQL」等の異なるものを指しているようですが、同じ(一連の)記事の中で言葉の意味を変えては読者は混乱します。
記事の始めに「この記事中のSQLとは~」ときちんと定義しておくべきです。

3.言葉の誤用
生島さんは「理論値」という言葉を何度も使っていますが、一般的な意味とは明らかに異なる使い方をしています。
本来「理論値」とは、「何らかの理論に基づいて算出された値」という意味であり、理論の無い(説明できない)「理論値」などありません。

4.他の人が納得していない意見を公理として扱っている
>SQLとオブジェクト指向言語を比べたら、数百~数千%の差が付く。
(上に挙げた言葉の定義の問題もあり)そもそも比べる事自体がおかしいのですが、意図を汲んで考えても到底理解できない数字です。しかし、記事全般においてこれが間違いなく正しい前提(=公理)のように扱われ、根拠は書かれていません。
確かに、この前提が正しいと仮定した世界においては生島さんの主張は正しいでしょう。その場合でもやはり記事の始めに「この記事では○○と仮定する」と明記しておくべきです。

5.議論の参加者を汚い言葉で煽る
活発な議論と炎上は違います。そして、活発な議論を促すためには、議論と無関係な煽りを排除し、新しい(そして意義のある)話題へシフトしていくように一つ一つの議論を収束させていく必要があります。そして、これを仕切るのはホストである生島さんの役目です。
(もちろんコメント欄は議論をするためだけの場所ではないので、感想と議論は区別する必要があります。)
生島さんはこれが出来ていないばかりか、自分から炎上を煽り、にもかかわらず炎上している状況や他の炎上させている人を嘆いています。これほど滑稽なことはありません。

反論があっても議論をする状態にないと判断してコメントを放棄している人も相当数いるのではないかと思います。これらを改善し有益な情報交換の場となることを期待しています。

よっしー

そもそもSQLとOO言語は適応分野が違うのだが、なんで単純に比べてSQLの方が効率や速度が上だという話をしているのかがさっぱり分からん。
私の知ってる限り一般的なDBエンジンはC系の言語で書かれているんだが。。。
生島さんがSQL言語でDBエンジンを書けば100倍以上の速度で動作する
DBエンジンが作れるんだねw

>非OO言語 < OO言語 30~50%
>非OO言語 < SQL 140~1000%
>OO言語 < SQL 200~2000%

nanashiさん、みなさん、おはようございます。

仕様書ではありません。過去をたどれる形で書かれていて、ただでさえ長い文章に毎回毎回、前提条件は書けません。

とりあえずの前提は、業務系の仕事である。SQLと他の言語を比べているのは、SQLでできることをSQLに任せているかどうか。ということを書いています。

理論値について、理論値としてひっくり返らないと何度も書いています。

C言語とアセンブラがどちらが効率的ですか?
工数であるならば、C言語、パフォーマンスであるならば、アセンブラ。

これは、人間がコンパイラより賢いとう前提がありますし、アセンブラはできるけれど、C言語はできない、または、その逆という人が入ってくると議論が成りたたないでしょう。(その前提をいちいち書かないと読めないですか?)

しかし、例えばこんな人が大勢現れるのです。

> 私は、過去にSQLが遅いのでSQLを崩して、C言語でJOINをやらせて高速化しました。
> OO言語ではないですが、今だったらC++を使うでしょう(なぜってハッシュクラス
> があるから)。

一見正しく見えるでは?

しかし、SQLでは理論値まで持って行けてないだけの話。個別の事情として、SQLのスキルが足りなかっただけです。これを正論とされては、議論は成りたたないのです。

もっとも、世の中のあらゆるものが理論通りには行かない例外が存在します。業務系の基幹システムで1~5%ぐらい、どうしてもSQLでは処理できない例外は存在しますが、いちいち、全部の例外を説明しては一般論はできませんし、システム全体を通せば誤差に落ち着きます。

例えば、これぐらいのコーディングであれば30分ぐらいを目安にしています。
http://www.g1sys.co.jp/seminar090515.html

特殊な例題として取り上げているのではなく、SQLが苦手とする(SQLに向かない)題材を敢えて選んでいます。単純なプログラムでは、お互いに短いから差は小さいけれど、SQLに向く複雑なプログラムを題材に選べば、もっと極端な差になるので避けています。

30分ぐらいでできれば、SQL文を書くのはかなり理論値に近い工数になっているはずです。Javaでコーディング量は5倍の400%ぐらいでした。(コーディングに要した時間は5倍以上でしたから、私はJavaに熟達しているとは言えないわけです)

工数はスキル差という個別の事情が如実に出るので、理論値として比べられるのはコーディング量しかありません。双方の技術に熟達していた場合、工数はコーディング量との比例の関係に近づきます。しかし、コーディング量が増えれば、ドキュメントも、ドキュメント間の整合性を取ることも、テストも、同時に増加するので、工数はコーディング量増加率の、更にウン倍になります。そのウン倍もまた、個別の事情ではっきりとは言えないけれど、必ず1以上になります。

OO言語で書いたコーディング量というのは、分割すればするほど、どうしても(SQLでやった場合に比べて)余分なマッピングが入るし、OO言語が発行するSQL文の要素は、効率的なSQL文で処理する場合の要素を最低限含み、それ以上になります。

ですから、最低限、コーディング量はひっくり返らない。
是非、ドキュメント含めご自身で試してみてください。

理論値を求めるならば、OO言語で書くアルゴリズムとSQL実行計画が一致する(までチューニングする)訳ですから、理論値として、SQLの方が工数・パフォーマンスともに効率的である。とはっきりと言えます。
(パフォーマンスについては http://el.jibun.atmarkit.co.jp/g1sys/2009/12/post-59d3.html を見てください)

経験則ですが、上のサンプルが30分で「できない」という人は、1~5%ぐらいが、10~50%ぐらいに感じるのではないでしょうか。10~50%であるならば、確かにとても例外とは言い難いので、私も都度説明をします。

その感覚で来られても困ると書いているわけで、だから理論値できてね。
ってことなのです。

「だから理論できてね。」
「だから理論的にきてね。」

では、普段、皆さんが「理論的でない」と言ってることになり、それは私の思いとかけ離れている。しかし、みなさんの議論の中に数字は基本的に入ってこないから、「理論値として」と表現しているに過ぎません。

これがまずかったのは謝罪します。
申し訳ありません。

工数・パフォーマンスでトレードオフがないのに、違う方法を選ぶということは、トレードオフしているのは「できる人が少ない」という「技術者のスキル」に他なりません。それが許されるのは、余程、マイナーで世間的に知られてないものでない限り、あり得ないです。

「RDBMSの普及率で考えればあってはならないこと」だと、当たり前のことしか書いてないのです。

宮崎牛

上流の技術者はSQLを高いレベルで習得すべき
http://el.jibun.atmarkit.co.jp/g1sys/2009/06/sql-9a31.html

私は上記の記事からこのコラムを読むようになったからなのか、生島さんの言っていることはほとんど理解出来るのですが、この記事だけを読んだ人は、

> 生島さんがSQL言語でDBエンジンを書けば100倍以上の速度で動作する
> DBエンジンが作れるんだねw

とか、

「SQLが遅いから他のプログラミング言語で書き直したら速くなった」

という事になってしまうのでしょうか?
たまにこういう意見出てくるようですね。
相手に言いたいことを伝えるのって本当、難しいんだなー。

ryo 改め 大藤雄久

生島さん、おはようございます。

コラムニストの申し込みを行いました。

一発目のコラムは

> 私は、過去にSQLが遅いのでSQLを崩して、C言語でJOINをやらせて高速化しました。
> OO言語ではないですが、今だったらC++を使うでしょう(なぜってハッシュクラス
> があるから)。

について書きたいと思っています。
いずれにしても白黒はっきりさせたいと思います。

では、また。

宮崎牛さん、おはようございます。

>> 生島さんがSQL言語でDBエンジンを書けば100倍以上の速度で動作する
>> DBエンジンが作れるんだねw
>
> とか、
>
> 「SQLが遅いから他のプログラミング言語で書き直したら速くなった」
>
> という事になってしまうのでしょうか?
> たまにこういう意見出てくるようですね。

そうなんですよね。
そういう反論はやめてください。という意味で、理論値まで突き詰めて考えて本当にそんなことが起きるのか?って書いているのですけどね。

「理論値」でというのは「どちらもベストにして測れば」って意味ですよね。

ぶっちゃけていえば、ひっくり返るのは単にスキル不足なのですけれど。

「スキル不足」って滅多切りにしても不満が来るし、柔らかく「理論値」でひっくり返るのか?ってのも通じない。

どう書けば分かるのか……。

大藤雄久さん、おはようございます。

それは良かった。
期待しています。

@IT自分戦略研究所 編集部

@IT自分戦略研究所の岑です。

編集部にて協議しました結果、
生島様のコメント欄での言動などに問題があるため、
コラムニストから外させて頂くことにいたしました。

何卒よろしくお願いいたします。

ななし

@IT自分戦略研究所 編集部さん

「だれ」を外したのさ?これじゃわからないよ。

@IT自分戦略研究所 編集部

>> ななしさま

お世話になっております。岑です。
生島様をコラムニストから外させて頂きました。
言葉が足りず、申し訳ございません。

AC/DC

ありゃりゃ。ついに除名か。
さすがに見過ごせるレベルを超えちゃった、ってことね。
生島さんの布教計画も大きく後退。

そのうち、別のブログか何かで、「エンジニアライフはレベルが低い」とか何とか書いてそうだ。

コメントを投稿する