100%としているのではなくベースです。OO言語にすれば30~50%効率(工数・パフォーマンス)が上がります。C.(非OO言語⇒OO言語)&(単純なSQL⇒複雑なSQL)は200~2000%200~2000%効率(工数・パフォーマンス)が上がるということです。OO言語でstatic見たいな使い方は、確かに差があるけれど誤差でしかないと。癌をほったらかして水虫の治療を言ってるだけと、何度も何度も書いている通りです。理論値は、個別の事情が挟まらない極小のプログラムで差を見ればよい。ソース量が倍になれば、工数は倍では済まない。ソース量nのm乗(mは1以上)に比例します。07:40なるほど了解です。ベースを100%として読んでました。・オブジェクト指向(プログラミング)とSQLとが、それぞれ出てきた年代など、概ね「どんな分野の業務をしているのか」とは無関係なお話をさせていただいたと思うのですが。分野が違えば不毛な水掛け論にしかならないのですね。大変に失礼をいたしました。08:43ひまひまさんスタックとかヒープとかおっしゃってますが、どうもあなたの議論には、根拠となるWEBサイトとかがリンクされておらず、ご自身の検証とかを提示していただかないと納得がいきません。staticがお嫌いなようですが、これもstatic関数が嫌いなのかstatic変数が嫌いなのかはっきりしません。Javaやオブジェクト指向には都市伝説が多いようなので情報は鵜呑みにしないほうがいいですよ。以下のリンクでは、メソッド関数って通常のC言語の関数と同じメモリの使われ方ようなことが述べられています。08:44私が言いたいのは何度も何度も書いている通り、誤差で他人を追求するならば、十分な差が付く方をもっともっと気にすべき。水虫の癌患者で考えればいい。医者という括りにされている状態では、癌に目を向けない医者は、医者としての矜持がないカスでしょう。癌を放置して、水虫の治療法で揉めるなんて、私の肉親が癌患者ならそんな医者は容赦しないし、同じ医者の立場でも許せない。ちなみに、みながわさんは医者の括りに入ってない人で、立場の違う人の水虫の治療法に絡むぐらい立派なら、なぜ癌を放置するのか?と言ってる。これも何度も何度も書いているけれど、分業体制にになれば、皮膚科の医者が自分の仕事をほっぽらかして、癌のことを考えてもおかしい。目一杯水虫の治療にこだわるべきですけれどね。私の人間性について書きたいなら、どっか他所でやってくれたらいい。彼らの目的が何にあるのか分からない。そんなに嫌いな人間の人間性を変えてやろうとか思っているのだろうか?だとしたら、大変ありがたい話だけれど、私の人間性は変わる分けがないからやめた方がいい。私の人間性が変わったら彼らに何のメリットがあるのかも理解ができない。09:15人としておかしなことをしていたら批判されて当然。09:34匿名さん、ひまひまさん、おはようございます。何度も何度も書いていますけれど、ここでは沿わないですよね。言語解説なんて要らないのです。それが悪いとは言わないけれど誤差なんです。そんな細かいことが気になるなら、「もっと大きい方をちゃんと考えてくれ」って言うことを書いているわけで、どうでもよいことばかりを気にするのか?私が自分の好きな方へと言われたこともあるけれど、小さい方しかみれてないですよね。水虫をどんなに治しても、抜本的な治療にならないって。10:49久しぶりでコメント(感想)を。気になったのは、「SQLはオブジェクト指向言語の数十倍の効率」という事。これって問題点、つまり「数十倍の効率」が出る部位はいった何?おそらく、A)データの永続化の効率B)データストアの操作効率C)データの集合としての設計などだと考えられます。このような「効率」が業務と開発そのものの効率へ結びつくという事。RDBMSは当然ながら、A,B,C他に最適化されるように発展してきたのですから、現状、効率がよいのは当たり前。いうよりは、もう少し範囲を狭めた基幹系業務を言っているニュアンスに感じる)ですから、必然的に(歴史的に)データストア(プール)ありきでの話になります。あるからこそ、「オブジェクト指向言語の」が気になります。理解している方は多いと思いますが、あえて書かせていただくと。C)オブジェクト指向は、データの永続化を云々するものでは無い。そもそも、データにある種の責任を付与するという考えの上に成り立っているから。D)一般的に、オブジェクト指向言語は、汎用言語でありSQLのような専用言語では無い。(C)について考慮されずに記事を書いたとすれば、これは無知としか言いようが無い。次に(D)を踏まえて書いたのであれば、当然であるが、比較すること事態が稚拙だと感じた。そもそも、汎用言語というのはデータの操作や永続化を効率化するための言語では無い。言え、「オブジェクト指向」という抽象的な単語は、これで括って論点を暈しながら話すにはもってこいである。読み手が勝手に色々に解釈しやすいからである。ものの解った技術者であれば、このような比較をあえて声高に言うとは考えにくい。(もちろん読み手がどうしようもない野菜だらけだと思って書くなら別である)また、単純に単語に反応するということ(人)も少ないだろう。すれば、OOPの理解が厳密さがどうであれ、比較の厳密さがどうであれ、過去記事からの流れを踏まえて「SQL知らないのが多すぎるのは問題だ」等の延長で読むべきで、妙に細部をつつく必要もないし、妙に釣られる必要は無いのではないか?(良い専用言語があるのに、なんで知ろうとしないわけ?それはまずいだろ?っていう感じの流れ。)と考えると、「ず~~っと言っている趣旨は変わらない」というのは間違いない。生島氏が言う「オブジェクト指向」では、純粋なオブジェクト指向という【事】【物】よりは、OOもよく知らん、SQLもよく知らん、で物をえらそうに作っている(言っている)人が扱う「偽オブジェクト指向絶対論?(なんじゃそりゃw)」を指している事も多い。オブジェクト指向言語で製作されたオブジェクト指向では無いアーキテクチャー(例えばO/Rマッパ)を指す場合もある。これはひっかかりやすい、オブジェクト指向として思わず括ってしまいそうになる。実際、世の中には、OO言語で製作したら=OO指向である、と広義に捉えすぎる技術者も多い。「知らない間に、OO指向で作ってるのです」とか、アホである。(もちろんプロモーションとしては有り!)・DB使えますよね?使ったことありますよね?・あります。・どう使いました?・普通にSQL発行するライブラリを使ってアクセスしました。気をつけないと釣られる。釣られた人たちは、きっと純粋かつ想像力のすばらしい人が多いのね。人と相対して「おまえの人間性は」なんていわないのに、なんでテキストだと言えるのかな・・・不思議。いずれにしても、読んで、色々と考えられるネタ投下ありがとうみなさん。12:00AC/DCさん、genekさんが書いている通り、「理論値で話している」というのなら、「SQLはオブジェクト指向言語の数十倍の効率」という大前提の根拠を、説明してほしいですね。ないと、AC/DCさんの『みながわさんが考えるところの「インスタンス」と「static」って何?』という質問に、ついにまともに答えなかったみながわさんと同じレベルでしか読んでもらえないと思いますよ。12:39oumiさん、こんにちは。これまた何度も書いている通り、仕様書は機械のための文章。これは人間に向けて書いている文章ですから、いちいち前提を書きません。ほとんどの人は理解していますから問題ないです。デファクトだからOO言語って書いていますけれど、OO言語に限らず何だっていいのです。RDBMSを利用する以上、SQLを十分に利用しなければ非効率である。それで、デファクトのOO言語を考えても、日常的に『できない人に合わす』ということが行われています。SQLについても同じです。OO言語の『できない人に合わす』は、こういう所で書くと問題になります。SQLの『できるようになれ』も問題になるわけです。それが逆だろう?ということしか書いてないのですけどね。日常的に『できない人に合わす』ということが行われるのは、いずれの分野でもおかしい。プロとして『できない人に合わす』をなくすべきでしょう。データ(永続性)に関するモノをできる限り汎用言語でやろうとするのも間違いですし、DB側で全部できた方がよいと、汎用言語の分野まで拡張するのも良くない(パーソナルなRDBMSとは呼べないAccessは例外として)きっちり線引きをして分業体制を組むべきで、その線引きは多数決でOO言語側に寄りすぎ。何度も何度も書いていますが、全部ストアドプロシージャにすれば、汎用言語側はパラメータを渡すことダンプ出力UIを受け持つことになりますが、これらはいわゆるFWの機能をフル活用して工数を下げることができます。下がりすぎてSQLを書けない技術者はほとんど要らなくなる。FWを作るぐらい楽勝!ってOO言語ができる本物の技術者以外はSQLへ移行するしかない。業界全体として、雇用調整中だからちょうど良いと思うのですけどね。本物だけがのこって、お互い尊重し合える環境になればよいと考えています。12:48こんにちは。生島さんのご意見の大部分は私も賛成です。>RDBMSを使う以上、SQLをきっちり使い切った方が工数、>パフォーマンスともに下がります。>技術者がOO言語もSQLもやらねばならない現状ならば、>まずは、全員がSQLに向かわないといけない。青汁も飲もうよ!!」ってなもんで、そりゃそうだと思っています。200~2000%ってすごいことですよね。SQLをがんばれば効率が2000%も上がるなんて。「例えば青汁飲んだら癌も治るよ!!」って言ってるくらい画期的なことですよね。その2000%効率をアップさせた状況を詳しく知りたかったからです。その回答が、>なぜ?意味が分からない。>例えばって書いているのにそれ理論値と違うがな。「あくまで例え話だから、癌が治るとは限らないよ。」ってことでしょうか?だとしたら非常に残念です。・実際問題としてSQLをきっちり使い切ると、どの程度の工数の削減と処理速度の向上が図れるのだろうか?といったことが気になります。データベースの種類や処理、ハードウェアやネットワークのスペック等が絡んでくるので、正確な値は出せないでしょうが。13:04genekさん、こんにちは。ループ(言語問わず)で処理なんてしてたら、大概が工数も上がるし、パフォーマンスも悪くなりますよね。いう話しかしてないと思うのですが。13:09あほか?さんみながわさんが答えられなかったのは、OO知識がゼロに限りなく近い人だったからでしょう。AC/DCさんにOOの知識がないと判断したのがどこだったのか知りませんが、ここではどうでもいいことですね。私は、AC/DCさん、genekさんが知りたがっている質問の答えを、私も知りたいと考えただけです。13:22>SQLとオブジェクト指向言語を比べたら、数百~数千%の差が付く。WEBで調べれば書いてあることでしょ。みながわさんは「それすら」しなかったんでしょうね。「インスタンスはどこでもドア!」なんて意味不明のつぶやきで多くの人の失笑を買ってたんですが。AC/DCさんの質問の意図は、別にインスタンスとstaticについて知りたかったわけではなく、「みながわさんが」どう考えているかを知りたかったんだと思いますよ。14:32エントリーポートさん、こんにちは。私の認識が間違っていたのかもしれません。さん>AC/DCさんの質問の意図は、別にインスタンスとstaticについて知りたかったわけではなく、>「みながわさんが」どう考えているかを知りたかったんだと思いますよ。WEBサイトや本に書かれていることしか思いつかなかったからじゃないですか。インスタンスとstaticについて自分独自の考え方なんてもってなかったからだと思いますよ。いう状況を読み取れないようじゃ生島さんとは勝負できませんよ。他の強力なコメンテーターに任せなさい。14:56別に勝負するつもりはないですよ。したいとも思いません。勝ち負けという低レベルなことに拘泥しているほど暇ではないので。質問の答えが知りたいだけですよ。15:35genekさん、こんにちは。いうか、その前提でなければ、パフォーマンスにそこまで差がつくとは考えられないので。違うなら、私もその方法が聞きたいです。16:17エントリーポートさん、genekさん、こんにちは。2000%は、対象が、非OO言語(OO言語でstatic)のような非道いものをベースにしていますので大きく書いています。やれば2000%も可能かでしょうけれど、現実は、打ち合わせとか、ドキュメントの何チャラとかのオーバーヘッドの方が目立って大きくなるので達成できない。オーバーヘッドを除いたら達成可能な数字です。OO言語や、O/Rマッパの良さは、ストアドプロシージャで分離開発したときに100%発揮できる。発揮できすぎてOO言語側の技術者が要らなくなるのが難点。FWを使えば新人君で十分になる。19:45失礼します。いままでさんざん、「技術者なら理論値で語れ!」とぶちあげておいて、ご自分が根拠を問われると「例えばのイメージです」って何なのでしょうか。「例えばのイメージ」が生島さんの言う理論値ですか?そんないいかげんな言葉遊びを「理論」と呼ぶとは。生島さんの作るシステムは「バグではない。仕様だ」というのがたくさんあるんでしょうね。Studioが提供するクラスを使ってDBにアクセスすれば、SQLなんかをシコシコ書くより、数十倍から数百倍の効率とパフォーマンスが得られます。え?根拠?それは私の経験から得たカンですよ。ついでに、次に生島さんの取る行動を予測してみましょう。1.「日本語能力低すぎ、わかる人にはわかっている、前提はわざわざ書いてない」と罵倒する。2.「カスの相手は疲れる」と言って、コメント終了にする。3.何事もなかったかのように、新しいエントリーをあげて、理論値への質問自体なかったことにする。自分が論じている理論の根拠すらまともに数値化できないなんて。技術者としては相手にするに値しない方だったのですね。19:52やっとネタ明かししたね。最初から前提条件についてきちんと説明すれば、醜態晒すこともなかったのに。言ってることって単なるトートロジーだよね。『SQLが絶対的に早い条件下ならSQLが早い』そんなのわかってるし当たり前すぎるしさ。大事なことなので2回言ってみたけどさ、そんなの敢えて論じる価値なんてないんだよ。その程度のことをそれ以上にフカしてれば、まあ炎上するよね?でも当たり前のこと言っても相手されないからね。いい意味でも悪い意味でも注目集めたし、そういう意味では成功なのかな?>これは人間に向けて書いている文章ですから、いちいち前提を書きません。>ほとんどの人は理解していますから問題ないです。これだけ炎上したのはその前提が誰にも伝わってなかったからだよね。19:59>OO言語や、O/Rマッパの良さは、ストアドプロシージャで分離開発したときに100%発揮できる。>ただ、発揮できすぎてOO言語側の技術者が要らなくなるのが難点。FW>を使えば新人君で十分になる。いう低レベルの仕事をSQL+DBで隠蔽してくれるならそれに越したことはないよね。汚いものが見えなくて、OOでビジネスロジックとUIだけ書けばすむならそんなにいい話はないよ。20:21来週のアップになったので。導出過程==RDBMSを使う以上、SQLをきっちり使い切った方が工数、パフォーマンスともに下がります。パフォーマンスはもういうのも馬鹿らしいので書かないけれど、RDBMSを使う以上、必ずSQLは必要です。その単純なSQLの要素は、複雑なSQLに必ず含まれることになります。複雑なSQLでは要素の重複はある程度避けれますが、単純なSQLではすべて書かざるを得ず、SQL文の合計だけでも、単純に書いた方が多くなります。そこにSQLで可能なロジックがOO言語に必要になる。分割すればするほどロジック内のマッピング要素が増えますから、工数が増えるのです。nnは1以上、ドキュメントと人数によって可変。コーディング量のn乗となりリニアよりきつく増加し、規模によって数倍にも数十倍にもなる。繰り返しますが、RDBMSを使っていて、SQLでできるものを他の言語で実現しようとすると、必ず、コーディング量は増え、パフォーマンスは落ちます。コーディング量が下がれば理論的に工数は下がります。前回のコメントに、以下に書いたのは、例えば......例え。そんな個別の事情は、個別の議論しかできない。議論の対象になっているものは、RDBMSは導入済みで使うか使わないかの差でしかない。使わない、使えない理由「個別の事情」の大半は「メンバーのスキル」「嫌いだから」それを乗り越えれば、他の事情ではひっくり返らない差が付く。技術者都合は、倫理的には理論値に差がないときにしかいってはいけない。「メンバーのスキル」は許せないわけでしょうが。そんなのが流行ったら困るのでしょうが。理論値でも現実にも有為な差は付かない。(慣れで補える)SQLを選択しないことは、結果から言えばOO言語でstaticより罪が重い。20:43前回のコラムで私のコメントに返信がなかったのはコメントする価値がなかったのでしょう。この「効率」が開発orユーザーの視点がわからない。両方から見てる?いや必ずしも比例しないでしょう。・・・やっぱりコメントする価値がないのでしょうかね、私は。それはさておき、コラムとコメントを読んで・・・そもそもの元コラムであった「static」は、あれはまぁ理解度など様々な理由により残念ですが、その辺は捨てて、システムが停止してしまう状況が発生するリスクがあまりにも少ないという、システムは稼動するんだ!ということを前提としていればstaticでもよいでしょう。拡大解釈な話として、ユーザー数10人、月3000件とユーザー数1000人、月100万件の購買データを扱うシステムを同じとはあまり考えられませんし。(インスピで理解して・・・)そんな同じ状況を想定してのコメントが少ないような・・・まぁ、前提がわからんと言われればそれまでですがね。比較にならないよ!って訴えているのですよね?でも比較されるから訴えているのだと思います。個別に1点だけ・・・anekdotenさん>『SQLが絶対的に早い条件下ならSQLが早い』>そんなのわかってるし当たり前すぎるしさ去年末頃のコラムだったろうか・・・そんな前提の状態でも炎上しましたよ。OOなら~とかSQLなら~とか。そもそも、RDBMSを利用している状況の『大部分は』当たり前の状態にあると思います。このコラムはその状況下においての話であると思います。ついでに、RDBMSを使わない選択肢がでたら次元も変わるため議論できません。いいですが・・・メアドはともかく、IPもわかっちゃうんですね。20:46はあ、とため息が出てしまいます。nこれが生島さんの理論値なのでしょうか?「これが理論値です」って、理論値の意味がわかっているのでしょうか。>他の事情ではひっくり返らない差が付く。「差が付く」根拠を「理論的に」書いていただけないでしょうか。そんなのは常識だ普通の人にはわかるそれは理論でも導出過程でもありません。技術者を名乗るなら、数値でお話しましょう。>SQLでできるものを他の言語で実現しようとすると、必ず、コーディング量は増え生島さんのご意見はわかりました。コーディング量が必ず増えるという根拠はなんでしょうか?技術者らしく、数値でお話していただけないでしょうか。21:05私の質問は華麗にスルーされましたが、まあそれは我慢しましょう。生島勘富さんは何か著書をお持ちでしょうか?技術的バックグラウンドの確かさを証明するために出版されることをお勧めします。ここでコラムニスト気取りもいいですが、いまどき商業出版はなかなか厳しいので、ブログの書きちらかし(本記事を含む)では太刀打ちできないシビアな世界ですよ。その上で、ご説の正しさを証明すべきです。@ITの編集に相談してみてはいかがでしょう?@ITの担当者も、ここまでこじれさせておいて放置ってのは、あんまりじゃないですかね。楽しませていただいたんで、どうでもいいですけど。いずれにしても、吠えっぱなしは損だと思います。老婆心ながら、御社社員の皆様の今後が心配になってしまいますので。22:42生島さん、エントリーポートさん、こんばんは。私の理解としては、データの通信量は同じで、データ取得以降UIまでの処理をなるべくSQLにやらせると、パフォーマンスに2000%もの差が出るというものでした。私の理解が間違っていたようです。通信時間の差が支配的になりますよね。処理結果を求めるためにアクセスする必要があるデータ量が多ければ多いほど、差は広がっていく。10,000件のデータにアクセスして1件のデータを取得する処理の場合、1回の通信に一律で1msかかるとすると、通信時間だけでSQL:1ms(ストアドプロシージャ1発)OO言語/非OO言語:1ms×10,000件=10s(全データ取得)の差が出る。22:57初めてコメントさせていただきます。生島さんの回答は回答になっておりませんのでちょっと書かせていただきます。・よってSQLはOOの@@@倍程度、生産性が高い・また、OOOな条件のデータ抽出(母数XXX件、対象@@@件)の場合、SQLのプロフェッショナルがSQLで作り上げる場合は***秒程度、OOのプロフェッショナルがOOで作り上げる場合は\\\秒程度かかる。・よってSQLはOOの???倍程度、実行速度が速いといった内容でも書かないと回答になりませんね。このあたり、実際にどうなのか興味がある部分ですので是非回答していただきたいところです。それから気になった点をもう一つ。・・・・・・と書かれていました。「これまでの蓄積」、「ユーザの要望」、「システムの性質」などはツール/言語選定の重要な要件になります。「個別の事情」ではなく「一般的な条件」だと思いますが。これらを無視してのツール/言語選定はあり得ませんし、あくまでも「理論」にしかならず、実業務的な話にはなりえないと思います。00:29一晩おいておくと、見事に発酵してるね。理論値についての明確な定義は、いまだになされてないね。効率について、ケイワイケーさんが書いてるね。http://el.jibun.atmarkit.co.jp/ityuutu/2010/05/post-bb97.htmlあと、生島さんの行動予測、吹いたよ、ONEOUTSさん。このエントリーもコメント書き込み不可が近いかな。05:49みなさん、おはようございます。コメントに対する前提。みなさん、あるいは宛名が書いてないものは、これまでの記述に対するものに対して、返しているもので、「俺はそんなこと言ってない」と言われても知りません。特定宛名の方に返していないときは、以前のエントリーのコメントまでさかのぼってお考えください。(一つのコメントにすべての前提なんて書けるわけがない)例えば、oumiさんのコメントにあるとおり、SQLは汎用言語ではないので、それを比較対象としている時点で、SQLでやるべきの意味は、普通の技術者は単純なSQL(O/Rマッパで隠蔽するのも含め)を使うか、複雑なSQLで一括処理をすることを指していると、わかるはずです。分からないというなら、あなたとはどこまで行っても理解し合えない。ここでコメントのやりとりをしても、お互いに何も生まないので、もうやめにしてください。06:40理論値について、どんな言語でやっても、コーディング量が個別の事情を排除する最低のラインです。それ以外は、個別の事情が最も大きなウェートになるので、個別の議論にしかなり得ない。私が見たことのない、みなさんの個々の個別の事情を出されても議論にはなり得ません。基本的には私の考える多いパターンを一般論として語ることになります。みなさんが考える個別の事情と違うと思えば、それはご自身で考えてください。それでは意味がないと思われる方は、読まなければいい。個別の事情を出してへこましたい。思うのなら、お互いに何も生みませんからどうか他所でやってください。私は神ではないので、個別の事情を出されても分かりません。何度か書いていますが、OO言語を出しているのは現在のデファクトスタンダードだから、OO言語に限らず、RDBMSを使うならSQLを使うべきとごく当たり前のことしか書いていません。RDBMSを使うとき、SQLでできることを他の言語で行えば、理論値として必ず工数が掛かり、パフォーマンスが悪くなる。理論値として超えることはない。数字では、単純なもので50%~100%、複雑なもの400%の差になります。http://www.g1sys.co.jp/seminar090515.htmlコーディング量のn乗の差は必ず付きますので、規模が大きくなればなるほど差が広がります。規模が大きくなればなるほど、できる人を集められない。個別の事情が無限大になるから、工数が無限大になりできなくなる。低い方は妥当な数字ですけれど、上は、巨大なPJで会話のペースでSQLが書ける人が何十人か居たらという、現実的にはあり得ない数字になります。私が十人いたらでっかいPJが終わるかっていったらケンカになってこれまた終わらないしね(苦笑)。現実の論は、すべてに個別の事情が挟まるので如何様にも解釈できます。2人月で作成して2時間かかるものを、1時間全部書き直して、処理時間を2秒にしたこともあります。工数だけでも40000%以上ですけれど、対象が非道かったらナントでも言える。そんな個別の問題を巻き込んでも何の意味もないでしょう。動かないコンピュータもありますから、それを直せば無限大なのです。理論値で考えれば、最後はコーディング量に行き着きます。みながわさんの論ではコーディング量に大きな差は付かないのです。(理論値)これは、若い人には分からないかも知れませんが、50代まで現役でいる人は、全部staticで書けば会話のペースで書けてしまいます。(その社内では、そういう文化ですから保守も早いです)SQLも突き詰めれば会話のペースで書けてしまいます。会話のペースで書けるというのは、理論値に近づくわけです。「保守できなくなる」も保守要員のスキルという個別の事情。ハード環境、要件による個別の事情。スケールアウトできない。ハード環境、要件による個別の事情。みながわさんに人格攻撃しかなかったのか?私は人格攻撃できるほどの人格者ではないので、そこは無視して読んでませんが、「正しいOO言語の使い方」をふっかけていった人がいなかったとは言えません。いう人たちに書いているのですが「正しいOO言語の使い方」を押しつける人たちは、みながわさんの個別の事情は一切考慮してない訳です。みながわさんが、個別の事情をコメントしても、そんなの関係ないとかいう人もいたような気がします。私は「正しいSQLの使い方をすべき」と一貫して書いています。一般的な「技術者が揃わない」という「個別の事情」があることは十分に承知していますが、揃う会社もあります。個別の事情を考慮しなかったら、当然、「正しいSQLの使い方をすべき」になります。みながわさんの「個別の事情」は無視し大した効果も見込めないのに攻めて、私には「個別の事情」で論戦を張ってくるのは、技術者としての資質についてダブルスタンダードで許せないと言ってます。人格は会ったことがないので知らないけれど、理論値でもなく「SQLはできない人が多い(もしかしたら自身が苦手)」という商業技術者が持ち出すべきでない「個別の事情」を乗せて議論に臨むのであれば、技術者じゃないわ(XXX)ってなるわけです。07:01理論値には意味がないのかというとあります。理論値はスキルの向上やツールで埋めた後の行き着く限界です。私は低い方の限界をキャップとするより、高い方の限界を設定して教育を行い、ツールを作っていくべきだと考えています。O/Rマッパは、できない人が多い、つまり無限大を避けるという現実を見たものですが、「できるように教育すればいい」という当たり前から逃げた結果です。理論値から、限界が高い方を選ぶ人が増えれば、教育方法ももっとブラッシュアップされるはずですし、ツールも向上していくでしょう。他人に技術論をふっかけていくほど向上心も技術も持っているなら、低い方を選ぶなよ。私がイライラしながらも1年以上も続けているのは、十分に向上心があるのに低い方を選んでいる人が多すぎるからです。IDEも、FWも、行き着くところまで行ってるから、それを追求しても差は付かないよ。11:29はっきり否定されましたので、かなり厳しく書かせていただきます。2番についてはWebサーバーを構築したりセキュリティーを考える立場(=プロジェクトマネージャーやリーダークラス)から考えると最低の内容です。以下、GoogleGuice(googleAppi)上でデータを利用する際の問題点のVideo内容です。http://www.youtube.com/watch?v=8RGhT-YySDY(Staticを使用した場合の問題は3分位からです)言っておきますが、GuiceだろうがSQLだろうがDB系(GuiceはDBとはちょっと違うからこうしました)からデータを利用することに違いはありません。貴方は業務系のエンジニアとおっしゃっていました。業務系は効率を優先するならセキュリティーを犠牲にして良いのですか?SQLを知っていれば、WebサーバーやGuiceからの警告は無視できるんですか?そしてこれらは数十%の誤差として考えて良いのですか?馬鹿も休み休み言ってください。前に貴方はおっしゃいました「Havingすらわからない奴が技術者なのるな」と同じことを言わせてもらいます。最後に貴方は戦わなくて良いです。間違った知識を世に広めるためなら。12:43生島さん、相変わらずわかってないね。生島さんが「理論値」って言ってるものには、何ら根拠がないよね。生島さん「数字では、単純なもので50%~100%、複雑なもの400%の差になります。大多数「へえ、でもその数字の根拠は?」ってなるわけ。それはチープな新興宗教の教祖が「私を信じて財産を寄付すれば死んだとき天国に行けるぞよ」ってのと一緒なんだよ。導出過程なり算出根拠なりを出してね、ってみんなお願いしてるわけさ。生島さんが人格者で、たいていの人が「この人の言うことなら信じてみてもいいかな」って思えるような技術者だったら、細かい根拠なんかは、とりあえずなくてもいいかもしれないよ。生島さんは、明らかにそうじゃない。人をカスだとかクズだとか言ってるんだから、人格だけで信頼してもらえないのは自業自得さね。生島さんは人間性について軽視してるみたいだけど、何かを広めようというときには、意外に重要なんだよ?だから自分の教義を広めたいと考えてるんなら、まず理論値とやらの根拠を上げてみてくれないかな?あとさ、使いもしないでO/Rマッパーを批判してるけど、いまどきO/Rマッパーが生成するSQLをそのまま使うなんてことやってるまともな技術者はいないよ。主キーで取ってくるとか単純なやつは別だけどね。O/Rマッパーだって、外部SQL書けるようになってるのはたくさんあるのさ。13:24訂正いまどきO/Rマッパーが生成するSQLをそのまま使うなんてことやってるまともな技術者はいないよ。↓いまどき、まともな技術者なら、O/Rマッパーが生成するSQLをそのまま使うなんてことやってないよ。21:49AC/DCさん・・・お前は一生Ruby(Rails)に関わるな。生島勘富さん一人のIT系のエンジニアとしてコラムや返答内容に文句を言わせてもらいます。技術者が技術を批判はしては良いが馬鹿にするようなことは決して言うべきではない。それぞれの技術には考え方や基づく経験及び知識があるんです。IT業界はホリエモンみたいな人は少数です。方は外人でも日本人でも職人気質の人が多い。職人に向かって「俺の車は安全装置はないけど速いから素晴らしい。お前の車は安全装置なんか付けてるから遅くて出来損ないだ。」とこのコラムは言っているようなものだ。Scholarにこんな言葉が表示されます。技術者(肩の上に立つ者)はこの言葉に代表される様に先人(巨人)の努力の上に技術や価値観を身につけます。先人の努力や理由を知らずに勝手に決め付けて、価値観や技術を馬鹿にするべきではない。それは技術者として卑劣な行為です。最後に『批判』とは、人やものごとの誤っている部分、よくない部分を論理的に(根拠を示して)『指摘』しその改善を求めることです。23:08AC/DCさん年末のコラムのとき、O/Rマッパー信者がうようよ居ましたよ。23:19一応言っておくと別にO/Rマッパーを擁護しているわけでも何でもないよ。使いもしないで批判するなってこと。23:42レーシングチームがあるとします。ある技術、ここではAというエンジンがあるとします。いまのつんでいるBというエンジンをAに積み替えるとラップタイムが最低10秒縮まるとします。そのうえBを使える知識があればほぼAを積むのには支障がないとします。Aを積まない理由が財政的なものやその他もろもろの要因ならば仕方ない。Bを積まない理由がエンジニアの「いや俺はAのことよく知らないから」とか「Aが好きじゃないから」っていうのはプロとしてどうでしょうか?俺はレースに勝つマシンを作るのが仕事なのに、それを果たすための行動をしていない。うましかといわれても仕方がない、って俺は思いますけど。いや、Aを使わないでもBを使ってAより速く出来ればそれでいいんですが......。あと、職人だからこそお互いの技術をぶつけ合ってより高い場所を目指すのが筋だと思いますけどね。技術について語り合い、その結果罵倒されようが、ぶん殴られようが、正論で叩きのめされてプライドがずたずたにされようが、自分自身が一生一品と思えるものに近づきたい。そのためにも学び続けないし、技術を盗み続けたい。向こうが間違っていると思うんだったら、それを論破できるだけのものを自分のものにしたい。言葉ではなくて作ったもので語れるようになりたい。職人って言うのはそういうものだと俺は思っているんですけどね。いう技術者に俺はなりたい。23:47結局、回答をいただける気配がないのでこの書き込みで終わりにしますが。生島さんがこのコラム、及びコメントで書かれているのは「SQLは効率がいい。