とあるソフトウェアエンジニアのブログ へのコメント http://www.ohfuji.name/ I Love AWPLOG Thu Feb 23 16:39:05 2012 hourly 1 http://www.ohfuji.name/ T1028の液晶パネルを交換してみた へのコメント http://www.ohfuji.name/?p=1782&#comment_11003 おおふじ 2011-11-24 18:05:52 http://www.ohfuji.name/?p=1782#comment_11003 そっか、残念ですね。 では、そのDIMMは、将来のMacBookにでも積みますわ。 T1028の液晶パネルを交換してみた へのコメント http://www.ohfuji.name/?p=1782&#comment_11002 げっこう 2011-11-24 17:34:54 http://www.ohfuji.name/?p=1782#comment_11002 流石おおふじさんw ロマン溢れる事を平然と!! ただ、うちのノートPC達に4G対応のは無いのです・・・orz 詳しい話はまた12月にでも。 T1028の液晶パネルを交換してみた へのコメント http://www.ohfuji.name/?p=1782&#comment_10992 おおふじ 2011-11-22 17:26:53 http://www.ohfuji.name/?p=1782#comment_10992 コメントありがとさん。 そうなんですよね。自分だけのマシンっていうのが良いですよね。 ちなみに以下の改造を画策しています。 ・SSD化  最近のSSDはプチフリしないようなので搭載してみたい。 ・搭載メモリの4GB化  メーカーのページによると搭載メモリはMAX 2GB だがチップセットのデータシートをみると微妙(ある型番では2GBだが別の型番では4GBまでサポート)こうなったら試しに4GBのDIMMを指してみないと・・・ダメだった場合欲しい? 4GB DDR2 SO-DIMMを買おうかとおもとります。 冷静に考えるとホントにロマンだけですね。 T1028の液晶パネルを交換してみた へのコメント http://www.ohfuji.name/?p=1782&#comment_10990 げっこう 2011-11-22 16:50:09 http://www.ohfuji.name/?p=1782#comment_10990 お気持ちわかります!ロマンですよね~ ただ、うちでも100%同じ事言われると思います・・・。 「分解」とか「改造」とかの言葉に胸が高まりますよねw 騙されないようにする為に(適切な議論の方法) へのコメント http://www.ohfuji.name/?p=1505&#comment_10794 ohfuji 2011-09-29 22:02:08 http://www.ohfuji.name/?p=1505#comment_10794 4週間になりますが、返信がございません。 出来ましたら、 『SQLはオブジェクト指向言語の数十倍の効率』 についてヤスさんのご意見をお聞かせ下さい。 私の返信も意地悪だったかもしれませんが、質問をしておいて音信不通になるというのはいささかマナーに欠けるかと思います。 ヤスさんのご意見では、『このように考えると、(RDBの場合)オブジェクト指向よりもSQLの方が速いシステムが作れるんじゃないかな、』ということですが、これは某社長と意見が一致しています。ヤスさん自体が実際にそうでなくても『やっぱり某社長のシンパはマナーが悪いな』と思われる恐れもあります。ので、そういう誤解を与えない為にも、お答え頂ければうれしかったりします。 ちなみに、ヤスさんのコメントを読んでからまとめ記事を出しています。徐々に充実させていきますので、そのうちにヤスさんの疑問も解消されるかと思います。 騙されないようにする為に(適切な議論の方法) へのコメント http://www.ohfuji.name/?p=1505&#comment_10710 おおふじ 2011-09-01 20:36:44 http://www.ohfuji.name/?p=1505#comment_10710 コメントありがとうございます。 せっかくのコメントで申し訳ないですが、1つといいながら複数の質問があり、かつそれらの質問の意図がわからないので答えられないところがありますがご容赦下さい。 まず、 >SQLでなくC++で動いているシステムがあったとして、 >はたしてそれはSQLを使ったシステムよりも速いのでしょうか? ケースバイケースでしょう。一連の記事の意図は、 『SQLはオブジェクト指向言語の数十倍の効率』 を否定するためのものです。ので全ての場合においてC++(ADP)がSQLより速いということは言っていません。ただ、JOINという極めて基本的な操作ですらC++(ADP)の方が速い場合があるということで上記の主張は強く否定されたでしょう。 もちろんですが、全ての場合においてC++(ADP)で組んだ方が速くできるとは考えていませんし、それが必要とも思っていません。ケースバイケースです。 せっかくコメントを頂いたので、こちらから1つ質問しますが、ヤスさんは 『SQLはオブジェクト指向言語の数十倍の効率』 についてどう思われますか? せっかくコメントして頂いたのにこのようなことをいうのはなんですが、文面から察するに、今回の例ではなぜJOINを崩した方が速いのか理解出来ていない印象があります。 もう一度この記事と、以下の記事を読んでみてください。 http://www.ohfuji.name/?p=115 http://www.ohfuji.name/?p=813 http://www.ohfuji.name/?p=1496 http://www.ohfuji.name/?p=1529 こういう突き放したことをいうのも如何なものかと思いますので一つ具体例を挙げます。RDBのJOIN&集計が遅いから作成されたアプリケーションサーバーがあります。 SQL Server Analysis Services(SSAS)といいます。なぜこのような製品が出てきたのかもあわせて考えてみて下さい。 騙されないようにする為に(適切な議論の方法) へのコメント http://www.ohfuji.name/?p=1505&#comment_10709 ヤス 2011-09-01 19:24:33 http://www.ohfuji.name/?p=1505#comment_10709 はじめまして。ヤスと申します。 一つ質問なのですが、よろしいでしょうか? SQLでなくC++で動いているシステムがあったとして、 はたしてそれはSQLを使ったシステムよりも速いのでしょうか? SQLのリターン速度が速いケースがあるのはよくわかりました。 (インデックスや、オプティマイザが判定をしている時間のロスについて考慮されていないのはおいておいて) しかし、これを実装した場合、アプリケーションサーバーの負荷が高くなってしまうのではないのでしょうか? 特に、複数のSQLを同時に処理しようとすればジョインによる負荷は高くなるだろうし、 GUIで表示をさせようとすればさらに重くなると思うのです。 まあ、SQLで処理をすればDBに負荷がかかるのですが、個人的にはDBの方が負荷が少ない気がしています。 もしも、ジョイン処理がボトルネックになった場合、 C++の場合は、DBサーバーとアプリケーションサーバーの両方を拡張しないとボトルネックが解消できませんが、 (場合によってはトラフィックも絡んでくると思います) SQLの場合は純粋にDBサーバーの拡張やインデクスの作成で対応が出来る可能性が高いと思います。 (基本的にはDBサーバー内に閉じているのでトラフィックは前社ほど考える必要はないと思うため) このように考えると、(RDBの場合)オブジェクト指向よりもSQLの方が速いシステムが作れるんじゃないかな、 と思うのですがどうなのでしょうか? 以上よろしくお願いします。 SQLの実行パフォーマンスについて 2010 へのコメント http://www.ohfuji.name/?p=115&#comment_10649 おおふじ 2011-08-11 12:29:48 http://www.ohfuji.name/?p=115#comment_10649 http://d.hatena.ne.jp/Sikushima/20110809/1312871002 ここは出入り禁止になったので、こっちに書いておきましょう。 この記事はもともと、@ITの記事の http://el.jibun.atmarkit.co.jp/g1sys/2010/05/post-2d1b.html にありました、 『SQLはオブジェクト指向言語の数十倍の効率』 を否定するための反例で、@ITの記事のコメント欄で、JOINの例を出されたからJOINの反例としてあげたまでです。 しかし、1年が経過し(私のこの記事を読んだのか)生島さんはツイッターで、 >JOINをなくすならAPサーバでキャッシュする。 集計関数をなくすなら、ORDER BYを禁止する。 SQLがイヤならRDBMSは使わないこと。 何度も書いているけれど、SQLで出来ることをAPサーバでやっても、【絶対に】DBサーバの負荷は減らない。 ただし、下手糞を除く。 と書かれています。つまりJOINの場合で、SQLより速くなるとご自身で言っておられます。これは私がこの記事と次の記事 http://www.ohfuji.name/?p=813 で指摘していることです。 であれば素直に一言「ありがとう。そういう場合もあるよね。」で済ませればよいのです。 それを >オマエのクソコードのどこにヒストグラムを測ってアクセスパスを決定して いる部分があるのか? と言ってしまうから話がおかしな方向に行くのと思うのですが? まぁ、言っても仕方がないのですが、気になることがありますので記事をあげて見ます。 追記、http://www.ohfuji.name/?p=1462 記事をアップしました。 ちなみに、誤解する人がいるかもしれませんので生島さんの質問に回答しますと、 >オマエのクソコードのどこにヒストグラムを測ってアクセスパスを決定して いる部分があるのか? コメント欄をよく読めばわかりますがxerenさんとの議論で答えは出ています。 またSQL側でJOINしたものが遅い理由は生島さんが、『JOINをなくすならAPサーバでキャッシュする』といっていることと同じです。生島さん自身そのことを解っているかと思うのですが、このような質問をしてくることに疑問を感じています。 SQLの実行パフォーマンスについて 2010 へのコメント http://www.ohfuji.name/?p=115&#comment_10647 おおふじ 2011-08-11 09:16:49 http://www.ohfuji.name/?p=115#comment_10647 おお、追加で記事を書かれていますね。 記事の内容的には面倒くさいのでコメントしませんが、 『SQLはオブジェクト指向言語の数十倍の効率』 という話は出てきていないようですので、これについては不正確であるとお認めになったと受け取ります。 SQLの実行パフォーマンスについて 2010 へのコメント http://www.ohfuji.name/?p=115&#comment_10646 おおふじ 2011-08-11 09:10:30 http://www.ohfuji.name/?p=115#comment_10646 残念ですね。 本当のエンジニアというのは、少なくとも技術面では真摯であるべきです。 貴方が、過去に 『SQLはオブジェクト指向言語の数十倍の効率』 という考えを持っていて、それに反する事実を見たとき、それを素直に受け入れるのがエンジニアというものです。 (例えばxerenさんのようにです)。 技術的な論争を行ったとき、その内容は素人には判断できないので、適当に言いがかりを付ければ議論が成立しているように見えるでしょう。ただそれは本来やってはいけないことであると思いますが? >それでも、もしSQLより速いモノが作れるなら私もRDBMSを二度と使いません。 私はこれからもRDBMSを使います。道具は適材適所で使えばよいのです。なぜこのような見苦しい言いがかりをいうのでしょうか? >出来ないなら文盲と判断しますので、二度と掛かってこないで。時間の無駄です。 これは私のブログなので別に私が自由に話しをするだけです。 こういう話をされるということは、 『SQLはオブジェクト指向言語の数十倍の効率』 は間違いであったとお認めになったと受け取ります。