そのあとで何で「全員がSQLをやるべき」ってなっちゃうの?SQLやるヒトとOO言語でUIや業務ロジック作るヒト、それぞれ必要でしょ?SQLでUIは作れませんよ(でもだからといって私は「OO言語のほうがSQLより優れている」などという暴言をはくつもりはありませんが)以上、私なりに「なんでこんなに噛み合ないかな」と感じた理由を整理してみました。09:48生島さんご返信ありがとうございます。子牛さんが興味深いコメントをされいますね。子牛さんのコメントに生島さんがどう返信されるか興味がありますので、よろしければそちらを優先させていただければと思います。私のコメントはその後にでもさせていただきます。09:55みなさんのおっしゃることはもっともなことも多いのですが、考えてみると「過去の記事を要約して、前提条件としてきれいにまとめたものを、まず記事の先頭に張るべきだ。10:06oumiさんはじめまして、ryoと申します。『SQLはオブジェクト指向言語の数十倍の効率』と書かずに『多くの業務アプリ開発では、SQLは、ORMを使ったオブジェクト指向言語の数十倍の効率』と書けば、少ない手間で多くの無駄な議論を省けるかと思います。10:40子牛さん、おはようございます。そんなことは、全部、過去のも含めて何回も何回も書いているって。毎回同じことは書けないって、これも何度も何度も書いています。一年半も同じことを何度も書いているけれど、テーマが大きいから一回では書ききれないのです。OO言語って言ったって数は何種類もあるんだから、自分の得意なモノで同じロジックを書いて比べたらいい。これも何度も書いているでしょう。ちなみに、これをJavaでわたしが書いたら約5倍で400%でした。http://www.g1sys.co.jp/seminar090515.htmlSQLは資料は移送項目ぐらいしか書きようがないけれど、Javaの方は相当な資料を書かねばなりません。それはどのレベルの資料を書くかはプロジェクト次第ですから差があります。大手で要求される資料レベルで考えれば2000%では足りない。現実のプロジェクトではもっと複雑なシステムはいくらでもあるので、複雑になればなるほど、巨大になればなるほど差が広がります。唯一絶対的に言えることは、理論値として工数とパフォーマンスの両方とも、絶対にひっくり返らない。全体最適化というのは、理論値として工数とパフォーマンスにおいてトレードオフが成りたつときに必要なモノで、トレードオフがないときには必要ない。現実には、どうしてもできない人(開発・保守とも)に合わせて最適化するだけです。それは、理論を曲げて、できない人に合わしているだけですね。最初に戻って、みながわさんに対して、お互いの人格攻撃なんてわたしは眼中にない。「炎上したコラムについて」その技術的なお互いのやりとりに対して、効果に差がないのに、社内SEとしての最適化の結果にガタガタいうな。そんなことを気にするなら効果がでるSQLをもっと気にしろよ。